Addressing Issues

[TTUAlex]

I am new to the world of 6502 and assembly language in general, and I have a question about addressing. How exactly does all this high/low stuff work? Say I look at address $20. Is this the low half of a 16 bit number with the other high half being at address $21? Can you think of even and odd addresses behaving as low/high pairs? Or am I missing the point entirely?

[Nightmaretony]

no, you seen to have it fairly right. I got a tad confused with the "little endian" bit, which is the LSB being first, THEN the msb (I was writing my code the other way around for results, bad habit to learn).

So fr example, if you have an address of $1234 and it stored at address $0000, you would have it like this:

$0000 $34
$0001 $12

And then to use the number...

LDA ($00),y
where the $00 points to the $0000 address as your pointer...

[dilettante]

There isn't any even/odd effect going on, don't get hung up there.

Without rehashing decades of big-endian/little-endian arguments (please, no flames, I'm just trying to help here), here is one rationalization leading to an aid to visualization:

Rationalization

We in the west are used to a left-to-right order for writing we inherit from Greek and Roman traditions, most of us from the left-to-right recording of Latin language. Therefore we tend to visualize linear sequences as proceeding from left to right.

However, we cribbed our system of recording decimal numbers from Arabic and other sources, where the languages are written right-to-left instead. As we worked with other number systems we naturally continued this approach (binary, hexadecimal, what have you). The low-order digits are at the far right and each higher-order digit is written to the left of it in sequence.

Even though our written number systems are right-to-left, we often try to impose our written language left-to-right linear sequence view onto "things numeric." This results in such bizarre constructs as "big-endian" computers.

Visualization

In order to help make more sense of little-endian computer systems, we need to treat our addressable units (bytes in this case) as digits. This is just as we would write the decimal number 254 in binary as 11111110 rather than 01111111.

So memory is addressed from right to left as in:

Code: Select all

   F  E  D  C  B  A  9  8  7  6  5  4  3  2  1  0

0 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00
1 1F 1E 1D 1C 1B 1A 19 18 17 16 15 14 13 12 11 10
2 2F 2E 2D 2C 2B 2A 29 28 27 26 25 24 23 22 21 20

... and so on.

The idea here being that rather than the usual way of visualizing memory, we need to view it as a right-to-left structure. This is one where address 00 (or for that matter 0000 for 16-bit addresses) appears at the upper right instead of the upper left when we use a 2-dimensional mental model. If we use a 1-dimensional fully linear view of memory, address 0000 is at the far right, and address FFFF comes at the far left of our string of memory locations.

Ok. Blah, blah, blah.

Here's an example:

Code: Select all

JMP $0200

One way (the conventional way) of looking at this in hex is as:

Code: Select all

4C 00 02

Seems confusing, no?

But if you realize that "things numeric" are supposed to be written right to left, where the first units come at the right and successive units follow to the left, we have:

Code: Select all

02 00 4C

This naturally means that an assembler listing should look like:

Code: Select all

0200  02 00 4C  LOOP  JMP LOOP  ;Infinite loop!
0203        CA  STRT  DEX
0204     0E 86        STX $0E
0206  DE 01 8D        STA $DE01

Notice how wonderfully this works out?

So why don't assemblers list code this way? The tyranny of the big-endians! Well, really it is because early western computer scientists were influenced by their written-language-inspired left to right bias, and the rest of us followed them like lemmings over the cliff.

I wrote a short paper on this in the early 1970s, drawing on sources as early as 1938. My professor made me destroy it in front of him and do another one, it irritated him so much. Ah, academia!

Here's a brief, reference-free writeup closely paralleling my original:

http://www.noveltheory.com/TechPapers/endian.asp

Here's a Jargon Dictionary entry on the subject as well:

http://info.astrian.net/jargon/terms/b/big-endian.html

[kc5tja]

dilettante wrote:

Even though our written number systems are right-to-left, we often try to impose our written language left-to-right linear sequence view onto "things numeric." This results in such bizarre constructs as "big-endian" computers.

The existance of little-endian has absolutely zero to do with our reading left-to-right. It has everything to do with the fact that the older 8-bit computers had only 8-bit ALUs, while address arithmetic required at least 16-bits of precision. Since the CPU already maintained a carry flag, by arranging addresses with the low byte first, followed by the high byte, it could use an 8-bit ALU to perform 16-bit address arithmetic, with only a single cycle penalty. It's like adding numbers on a piece of paper: you start with the least significant digits first, and carry over into the next left-most digits.

Big-endian processors, however, require more transistors to temporarily store the high byte of something while the low-byte is being fetched and processed. This adds transistors, complicates the logic, and requires a minimum of two overhead cycles, assuming an 8-bit ALU. Knowing this, big-endian processors aren't terribly bizarre -- just different. It's quite likely Motorola used this approach in their 6800 line to circumvent patent issues. It became a bit of a trademark, and found itself also in the 68000.

If your ALU matches the native word size for the processor, then no overhead is necessary. It doesn't matter if it's little- or big-endian -- everything gets done in a single cycle anyway.

[dilettante]

kc5tja wrote:

... big-endian processors aren't terribly bizarre -- just different.

Please keep in mind that my post was somewhat tongue-in-cheek. I had hoped the hackneyed "lemming" reference would have been a tip-off.

kc5tja wrote:

The existance of little-endian has absolutely zero to do with our reading left-to-right.

I think you may have gotten my point backwards though. I should have taken the time to be clearer.

My actual hypothesis was that little-endian architectures are perhaps more "natural" from a hardware-minimalist perspective, and big-endian ones are the result of a left-to-right visualization bias. As you point out, big-endian machines spend more hardware buffering high order bytes (or words) when they need to perform operations on data larger than their ALU width. So on the surface there seems to be no good engineering reason for creating big-endian machines. For extended precision beyond that offered by the hardware programmers on big-endian machines often resort to a mixed-endian format to save on instructions.

Arguments about something like this would be silly and were done to death decades ago. It wasn't my intent to add to them. Computing's holy wars have generally been trivial and futile, and seldom resolved anything. We use what is put in front of us.

Where I was going was that multibyte operands and addresses in 65XX machines are easier to visualize if one uses the right-to-left model because 65XX processors are little-endian. Thus my funky "assembler listing" example.

[GARTHWILSON]

There's more discussion on this under
6502.org Forum Index -> Programming -> 6502 ISA clarification please
showing how the byte order is important for the 6502's speed advantage over other processors in its class. It allows the 6502 to do several operations per clock, so each instruction takes very few clocks.

[orac]

Hi Everyone,

What about bit-ordering?
The PowerPC has bits ordered
from left-to-right. So....

Bit-zero can be:

2 to-the-7 ==> 8-bit reg.
2 to-the-15 ==> 16-bit reg.
2 to-the-31 ==> 32-bit reg.
2 to-the-63 ==> 64-bit reg.

This plays havoc with PPC computers
that have a PCI bus. This is because PCI is little-endian and
uses right-to-left bits.

How come nobody invented a term
to describe bit-ordering?

Cheers,

Paul