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

Reply via email to