AMU compile errors

How do you get AMU to display the line a compile error occurred on?

I can’t see any setting for it in the setup or options. I guess I’m just missing something blindingly obvious!

Do you not simply add the switch -throwback to the CC (or ASM or CPP) flags?

Figured it out, you need an editor loaded that supports throwback – knew it was something obvious.

you need an editor loaded that supports throwback

There’s one in the DDE, and at the risk of a small outbreak of Zap vs. StrongED they support throwback too.
“Too”?? I suspect most people use SE/Zap

I just happened to have StrongED loaded when I was trying to compile, which is how I discovered what “throwback” was.

Just need to figure out how to set 32bit and CPU flags now. Major uphill learning curve ahead of me I think. It doesn’t seem to warn about LDM^, so it must be defaulting to 26bit. I had a look at the manual, which didn’t seem to help much, I couldn’t see any mention of what CPU values you could use.

As you are using AMU, you will be using a MakeFile.

Here’s the one I use to build my OLED module. Feel free to steal ideas. ;-)

# Project: OLED 

# Toolflags:
CCflags      = -c -depend !Depend -zM -I,C: -apcs 3/32bit -Wcd -throwback -fahn 
Linkflags    = -m -o $@ 
CMHGflags    = -throwback -32bit
ObjAsmflags  = -APCS 3/32bit -desktop -Depend !Depend -ThrowBack -Stamp -IC:,
Squeezeflags = -f -o $@

# C files used (referred by object file, linked in ORDER)
c_files      = o.module o.oled o.iic

# Assembler files used
s_files      = o.dadebgptch o.swicalls

# What to do to build the MIDI module (list is in REVERSE order)
all:       addmsg OLED clean

clean:
           Stamp @.cmhg.ModHeader
           # This forces a rebuild to keep the embedded date correct

addmsg:
           appendmsg
           # It isn't so easy to poke easter-egg text to the end of
           # the module in a compiled module; so this will instead
           # poke it in place using a short BASIC program. ;-)
           
# How to build the module
@.OLED:    @.o.ModHeader $(c_files) $(s_files) C:o.stubs 
           link $(linkflags) @.o.ModHeader $(c_files) $(s_files) C:o.stubs 

# How to build the module header
@.o.ModHeader: @.cmhg.ModHeader
           cmhg $(cmhgflags) @.cmhg.ModHeader -o @.o.ModHeader
           @echo ***> HEADER REBUILT

# A macro for building the C code
.c.o:;       cc $(ccflags) $< -o $@

# A macro for building the assembler code
.s.o:;       objasm $(objasmflags) -from $< -to $@


# Dynamic dependencies:

I can’t find half those options in the ASM manual, so have no idea what they all do. Are the manuals that come with DDE up to date?

For example, I’m looking at the “Assembly language interface” example in C_C++.PDF (p294) and it shows the exit back to C as “LDMEA fp, {v1, fp, sp, pc}^” which clearly isn’t correct on modern CPU’s/APCS. I presume you simply drop the ^ or have other things changed with the current APCS standard?

I’m also seeing a lot of “Deprecated instruction (STM with SP in register list)” – Can I safely ignore those when interfacing C with ASM?

I can’t find half those options in the ASM manual, so have no idea what they all do. Are the manuals that come with DDE up to date?

I think some of those options aren’t up to date. For starters “stamp” has no effect on current releases of objasm.
Usual methods of finding out the available options – type objasm on its own in a task window and save the output.

I’m also seeing a lot of “Deprecated instruction (STM with SP in register list)” – Can I safely ignore those when interfacing C with ASM?

This is where I’m coming from when I speak about needing simple guidelines for 26 —> 32 bit changes.
Rick was a bit sniffy about whether those who don’t know should really be twiddling in any way.

You might get a few useful clues by taking an item compiled for 26 bit and doing a reverse engineering job with an intelligent tool.
SID from the DDE package for example, will give you “source” that uses macros – you can then study the macros and indeed use tem for new jobs.

For example, I’m looking at the “Assembly language interface” example in C_C++.PDF (p294) and it shows the exit back to C as “LDMEA fp, {v1, fp, sp, pc}^” which clearly isn’t correct on modern CPU’s/APCS. I presume you simply drop the ^ or have other things changed with the current APCS standard?

Dropping the ^ should be all that’s needed for that case. There’s an overview of APCS-32 here, and IIRC there’s also a doc about it in the CodeStds (?) folder in the C tools.

I’m also seeing a lot of “Deprecated instruction (STM with SP in register list)” – Can I safely ignore those when interfacing C with ASM?

Yes, those can be ignored. IIRC that’s an instruction type which ARM deprecated in rev B of the ARMv7 ARM, but then went back on that decision in rev C of the document – and objasm hasn’t yet been updated to reflect that. Either way, it’s fine on the current generation of chips, and we’d have major issues with all compiled C if we had to port the OS to a chip where it didn’t work!

I’ve got the ASM side compiling okay now, thanks for the help so far.

Now that I’ve added one C file into the project and tried to compile it, AMU is crashing, any ideas what the problem might be?:

Norcroft RISC OS ARM C vsn 5.70 [12 Oct 2012]
“C:h.event”, line 43: Error: prototype and old-style parameters mixed
AMU: * Internal error, no stack for trap handler: Internal error: abort on data transfer at &021C7008: registers at 000ABC10 *

EDIT: Its throwback from CC under AMU that’s generating this error as it compiles the C file in CC okay and shows the throwback errors. When the error occurs under AMU, a blank Throwback window appears and then AMU crashes