68300

I am porting some CPU16 code in which the addressing was performed using
ZK:ZX = 0 and the SCIM control registers were accessed at negative 16-bit
displacements from the index register.

I like this addressing mode, which would be (d16,An) in CPU32.  I am trying
to determine if address calculations are full 32 bit in the 683xx or if they
are still 24 bit addresses with roll-over.

IE, if the scim registers are at $FFF800-$FFFFFF, are they only at $00FFF800
or at $xxFFF800?

I was off doing microwaves and RF the entire period of time between learning
6800 assembly in 1983 and self-teaching the extension to CPU16 a couple
years ago.  I missed the entire 68000 family until a month or so ago and I
am slowly learning it...  I have P&E Micro assembler, so using C and letting
the compiler deal with it isn't an option...

Does the scim map to $FFFF F800?
Is (d16,An) really going to save as many clock cycles and bytes over direct
32 bit addressing as it appears?

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





"Jeff Andle" <andle@...> on 09/20/2002 08:11:49 AM

Please respond to 68300@yahoogroups.com

To:    <68300@yahoogroups.com>
cc:

Subject:    [68300] 683xx address space and modes...


I am porting some CPU16 code in which the addressing was performed using
ZK:ZX = 0 and the SCIM control registers were accessed at negative 16-bit
displacements from the index register.

I like this addressing mode, which would be (d16,An) in CPU32.  I am trying
to determine if address calculations are full 32 bit in the 683xx or if
they
are still 24 bit addresses with roll-over.

IE, if the scim registers are at $FFF800-$FFFFFF, are they only at
$00FFF800
or at $xxFFF800?

I was off doing microwaves and RF the entire period of time between
learning
6800 assembly in 1983 and self-teaching the extension to CPU16 a couple
years ago.  I missed the entire 68000 family until a month or so ago and I
am slowly learning it...  I have P&E Micro assembler, so using C and
letting
the compiler deal with it isn't an option...

Does the scim map to $FFFF F800?
Is (d16,An) really going to save as many clock cycles and bytes over direct
32 bit addressing as it appears?




---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

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

Jeff,

>
>Is this a problem with the assembler?
>

Sounds very much so. I don't know the P&E assembler, but I have
written several assemblers and one of the issues I had to face
was signed versus unsigned constant handling. Basically,
if the assembler tries to fit -1 ($ffffffff) into a word and treats
that as unsigned, it will (and should) fail. My soulution was
to add tags for all specific cases (4 of them because there is also
the linker interface) which indicate signed vs. unsigned numbers.

 In your case, fitting a negative number into a word might be doable
by anding it with $ffff (since you know it fits in 16 bits), something
like

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

where !. is the symbol for logical AND (I wonder if anyone else
still uses it, my assemblers accepts the & as well, of course).

Dimiter

------------------------------------------------------------------------
Dimiter Popoff
http://transgalactic.freeyellow.com   <---- now with the new Nukeman

On Fri, Sep 20, 2002 at 11:11:49AM -0400, Jeff Andle wrote:

> I have P&E Micro assembler, so using C and letting the compiler deal
> with it isn't an option...

you have no excuses.  :)  the GNU project has a freely-available
toolchain for 68000 and 68HC11/12.  source and binaries are freely
available for download at multiple ftp and http sites.

http://billgatliff.com/twiki/bin/view/Crossgcc/WebHome
http://sources.redhat.com/ml/crossgcc/

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron@...