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.
signature.asc
Description: Digital signature