68300

I started switching over to absolute short addressing...
I am using the P&E Microsystems assembler.
I am placing the SRAM at $FFFFD000, below the SCIM registers.
I then equate my variables relative to SRAM.
I suppose a more elegant approach would be to org $FFFFD000 then use dw.

SRAM                 EQU        -$3000               ; Base of SRAM relative
to 0
CALBOUNDS    EQU        (SRAM+$9C)    ; for comp2 test of 0..99

        move.w  #$FF64,(CALBOUNDS,a0)  ; 0..99 bounds

This works.  But:

        move.w  #$FF64,(CALBOUNDS).w  ; 0..99 bounds

does not assemble.  It gives an error:  "Parameter does not fit in a word".

    IF I make the base value of SRAM positive, then both approaches work.

I take it that P&E assembler is unwilling to truncate a signed parameter to
a word.
I take it that the first version is being interpreted as (d32,A0), NOT
(d16,A0)

Is this a problem with the assembler?

Jeff Andle

----- Original Message -----
From: jeffrey.tenney@...
To: 68300@yahoogroups.com
Sent: Friday, September 20, 2002 12:49 PM
Subject: Re: [68300] 683xx address space and modes...



Jeff,

The (d16, An) addressing mode is very efficient.  However, "Absolute Short"
[ (xxx).W ] is just as efficient on the CPU32.  The instruction size is the
same, and the execution time is the same.  As long as you define your SIM
addresses starting at $FFFFF800 (*not* $xxFFF800 and *not* $FFF800), the
assembler will see that the target address fits the absolute-short
requirement, which is that the address (viewed as a signed 32-bit value)
must fit into a 16-bit signed number.  Another way of saying it is that if
you sign-extend the 16-bit value, you get the correct 32-bit value.  This
is true of all SIM addresses if you start them with $FF, as in $FFFFF800.

By the way, the addresses are all calculated and stored using full 32-bit
arithmetic.  However, before being used externally *or* internally as an
address to read to or write from, the address is chopped to 24 bits.
Therefore, the SIM registers are available at $xxFFF800 - $xxFFFFFF

By the way #2, "Absolute Long" [ (xxx).L ] is slower than (d16, An) and
absolute short.

Good luck,

Jeff