On Wed, Oct 15, 2008 at 07:49:19PM +0200, Robert Millan wrote:
> On Wed, Oct 15, 2008 at 06:12:23PM +0200, Robert Millan wrote:
> > On Wed, Oct 15, 2008 at 03:16:56AM +0100, Ben Hutchings wrote:
> > > It's for a Motorola 56000 (aka DSP56000 or DSP56K) processor, which is a
> > > different architecture but maybe with some similarities. I doubt we
> > > have any of the necessary tools but the code is short enough to hand-
> > > assemble.
> >
> > I found an assembler, "a56" (see http://www.zdomain.com/a56.html), which seems
> > to be DFSG-free (BSD-style license). I'll see about packaging it.
>
> Gah, there's a bit more to this:
>
> - First I had to run "frodos" on bootstrap.asm to cleanup the CRLF.
I think that's introduced by the BTS.
> - Attached patch fixes a few errors spit by a56. I think my other two fixes
> are correct, but I have no idea what the '<' / '>' candy is supposed to do
> (hints?).
According to the assembler reference manual
<http://www.freescale.com/files/dsp/doc/ref_manual/DSPASMRM.pdf> they mean:
<< - I/O short addressing mode force operator
< - Short addressing mode force operator
> - Long addressing mode force operator
> - Resulting offsets doen't match with the blob. I still haven't figured out
> how are program code offsets mapped to the output file, but some parts
> don't match. For example, the blob has a jump (0C 00 40) to 0x40
> (and so does a56 output, at offset 0x0 in both cases), but then code
> from the blob continues at 0xc0, unlike code from a56 which continues at
> 0x40. Is there some trick to this?
It's a 24-bit processor and uses word-addressing, not byte-addressing.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
Attachment:
signature.asc
Description: Digital signature