Coldfire mcf54418 CAU assembly

Showing results for 
Search instead for 
Did you mean: 

Coldfire mcf54418 CAU assembly

Contributor I

I am using the CAU on MCF54418.   The compiler is GCC. I have got the "" from NXP.

But the GCC can not identify the  CAU commands, such as cp0ld.l , cp0st.l, etc.

The assembly codes below can not through compiler.

cp0ld.l (%a2)+,&LDR+CA0 # h[0] -> CA0
cp0ld.l (%a2)+,&LDR+CA1 # h[1] -> CA1
cp0ld.l (%a2)+,&LDR+CA2 # h[2] -> CA2
cp0ld.l (%a2)+,&LDR+CA3 # h[3] -> CA3
cp0ld.l (%a2)+,&LDR+CA4 # h[4] -> CA4    

I wonder to know, how can I use the source codes in  " " with GCC ?

Thanks a lot.

0 Kudos
2 Replies

Specialist I

I don't know how or even IF you can use that code with gcc. That code probably one works with CodeWarrior.

The C language is standardised, but pretty much all assemblers are different to each other. They have different ways of specifying registers, immediates, and even use different characters to specify comments.

For instance, your example is using "#" as a comment character, whereas that's used as the "constant" designator in gcc.

I've just proved that gcc is able to assemble these opcodes, first by running "strings" on the assembler to see if it contains those opcodes (it does):

tevans@p1 ..ares/projects/cdd_root/cdd_kernel/adl3 (git)-[6.03] % strings /opt/cross/m68k-elf/bin/m68k-elf-as | grep cp0ld

Then google found me this page:

That contains sample code that gcc likes. For instance, one of the simplest opcodes is AESR, and this works:

    #define MCFCAU_AESR     (0x0E0)

    asm("cp0ld.l    %%d0,%%d0,#1,%0" : : "n"(MCFCAU_AESR));

The NXP example for the same thing in the MCF5441x Reference Manual is just "cp0ld.l #AESR", so you can see there's a big difference.

I'm guessing you (or someone else) will have to translate all the opcodes in the NXP library for gcc, or use (or adapt) the patch in the previous link.


0 Kudos

Specialist I

I expected the definition of the Assembly Instruction Format for the cp0ld and cp0st instructions to be in the "CFPRM.PDF" (ColdFire Family Programmer's Reference Manual). It isn't. That was last updated in 2005.

So I would expect it should be in the "3.3.2 Instruction Set Architecture (ISA_C)" section of the Reference Manual. It isn't, and it refers to the "ColdFire Family Programmer's Reference Manual".

The instructions are detailed in "26.3.2 Coprocessor Instructions".

The example assembler syntax for the CAU is:

    cp0ld.l    <ea>,<CMD>    ; coprocessor load
    cp0st.l    <ea>,<CMD>    ; coprocessor store

The <ea> field specifies the source operand (operand1) for load
instructions and destination (result) for store instructions.
The basic ColdFire addressing modes {Rn, (An), -(An), (An)+,
(d16,An)} are supported for this field. The <CMD> field is a 9-bit
value that specifies the CAU command for an instruction.

The above is probably what the GNU Assembler expects - with the "<ea>" field not being optional, even for instructions that don't use it.

The "/mmcau_lib_release/cau/README.txt" file says:

These functions are written in the ColdFire assembler used by the Core &
Platform design team. This assembler may not be compatible with the wide
assortment of other development tools, but typically can be easily translated
into the required format.

One particular item related to porting deserved mention: compare instructions.

So they expect you (or someone else) to translate it. The item about "compare instructions" is that different assemblers disagree on which way around the comparison instructions should go. Some assembly standards have "compare a, b" followed by a test mean "a > b" and others mean "b > a", depending on on whether the assembly format is "left to right" or "right to left". Except the original Sun M68k assembler was used by PDP-11 assembly programmers and they got annoyed that the two assembly languages had the opposite format, so they changed their M68k assembler to reverse the "compare" instruction operands so they wouldn't get confused. But so everyone else would because that assembler does the OPPOSITE of what the Motorola assembly documents said. That's what the README is warning about. No, I don't know which way around the GNU assembler is for these instructions.

There should be some documentation on the GNU Assembler that details the specific assembly formats, including the one used for these instructions, but I can't find any.

So I guess you have to read the SOURCE CODE for the GNU Assembler to find out what it expects!

Which is here, together with the explanations of the patch that added this functionality:

It also has an attached "cf_prm_coproc.pdf" file which I can't find anywhere else (so grab a copy) which also details the instructions and also explains the extra fields that seem to be in the GNU Assembly that the NXP document doesn't mention (Op,.size <ea>, Rx, ET, cmd). The "ET" field seems to be zero for the CAU, so NXP don't document it, but are in the following, and the GNU assembler seems to want it:

I'm SO glad the CPUs we use have the MDHA and SKHA. They're so much easier to use than the CAU.


0 Kudos