On Sat, Jun 02, 2012 at 12:11:38PM +0000, John Tytgat wrote:
> Yes, in Acorn/objasm and ARM Ltd's assembler documentation, only ":LNOT:"
> (with 2nd column) is mentioned, not ":LNOT". I know ":LNOT" gets accepted
> by objasm and to me it looks like a bug and decided not implement this.
> There were several similar instances in Castle's RO sources which all got
> corrected when AsAsm was tested.
Fairy snuff.
As you might have worked out, I was trying to build the Raspberry Pi sources
with asasm, and ran into a few problems. That one is trivial to fix, but
came across a few more things:
asasm/targetcpu.c is somewhat odd. There's a list of architecture types
('5TEJ') and a list of CPU cores ('ARM968E-S'). You can supply either with
-cpu to asasm. If you supply a CPU core, it converts it to an architecture.
But if you supply an architecture, it looks for a CPU core that implements
it, then uses the given architecture. But this means asasm needs to be
kept up to date with every core. If I supply an arch of '6Z' (as the ROOL
build system does), the lookup falls over because it doesn't know a CPU
core that contains it. But why should it need to do this arch->CPU->arch
lookup at all?
objasm now has a {UAL} predicate. asasm seems to have support for UAL in 32
bit (non-Thumb) mode, but not the flag. The BCM2835 HAL has a tiny amount
of UAL code, and all of that has conditional assembly with non-UAL
alternatives available. So in this case defining {UAL} = FALSE would
probably suffice.
-fpu gives an error. This causes the ROOL build system to bail and revert
to CPU arch 5TEJ. I'm not sure the best way forward here, but perhaps not
exit(1) if -fpu is found (ie just report a warning, but continue anyway)
even if it doesn't actually do anything. Then ROOL's script won't think
that something bad happened and assume an out of date objasm.
So far I've got it to ROM linking stage, when it causes an internal error in
Norcroft C (probably I need the latest version). But looks like asasm only
needs a few tweaks to work.
You may be interested in my bounty suggestion for improving the situation:
https://www.riscosopen.org/forum/forums/8/topics/1069
Theo
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment