big, little and middle endian-ness
C Lamb
am way too young to know about the origins of these 3 types. I used
to program on 6502 and if I wanted to represent a 32 bit number I
would do it so:
num=0x12345678
at address 00 value 0x12
at address 01 value 0x34
at address 02 value 0x56
at address 03 value 0x78
It seemed resonable to me to to have MSB at the left and LSB at the
right. Obviously this wasn't so for others so, which was natural for
you and what influences were operating on h/w designers to influence
the final result as big/middle/little endian?
regards
C
William Hamblen
: It seemed resonable to me to to have MSB at the left and LSB at the
: right. Obviously this wasn't so for others so, which was natural for
: you and what influences were operating on h/w designers to influence
: the final result as big/middle/little endian?
Oh, No, Endian Wars!
John West McKenna
>It seemed resonable to me to to have MSB at the left and LSB at the
>right. Obviously this wasn't so for others so, which was natural for
>you and what influences were operating on h/w designers to influence
>the final result as big/middle/little endian?
In the case of the 6502, there was a very good reason for little-endian.
Consider the instruction LDA $1234,X. Since X is only 8 bits wide, you
only need to add the low byte of the address, and sometimes add the carry
into the high byte. Since the 6502 is little-endian, they can load the low
byte, do the addition while the high byte is being loaded, and then load
from memory while they're adding the carry into the high byte. If there
was no carry (which is true almost all of the time), you can stop there.
If there was a carry, you need another load to get the correct byte. Saves
a cycle most of the time.
STA $1234,X is different, since you can't store to an address that might be
right - you have to make sure it is. So STA always takes 5 cycles. LDA
usually takes 4, 5 if you're unlucky.
This method isn't entirely without side-effects, however. Some I/O devices
will take action if you read from a location (like clearing IRQ flags), so
unexpected things can happen. But your code has to be doing very strange
things for this to happen by accident.
John West
lis...@zetnet.co.uk
On 1998-12-27 cs...@stoat.shef.ac.uk said:
:Not really a burning question that needs answering immediately, but
:I am way too young to know about the origins of these 3 types. I
:used to program on 6502 and if I wanted to represent a 32 bit
:number I would do it so:
:num=0x12345678
:at address 00 value 0x12
:at address 01 value 0x34
:at address 02 value 0x56
:at address 03 value 0x78
Erm, maybe so, but in its addressing the 6502 was little-endian. (In
some circumstances it didn't even bother incrementing the high word of a
pointer for indirection, though that was a bug and got fixed.) Of
course, since it lacked any concept of double-precision arithmetic you
could use whichever endianness you preferred. The 6800 was big-endian,
as were (I believe) all of the Motorola processors.
:It seemed resonable to me to to have MSB at the left and LSB at the
:right. Obviously this wasn't so for others so, which was natural for
:you and what influences were operating on h/w designers to influence
:the final result as big/middle/little endian?
It seems reasonable to do it that way, only because Western humans are
accustomed to reading numbers from left to right. Computers aren't so
concerned with reading numbers as with adding them, and like us, they
add from the LSB; if you use a little-endian architecture you can
increment a pointer through your "digits". Useful for a microprogrammer.
Useful for other programmers is the fact that if you fetch a byte from a
memory address defined as a word, you get the LSB - which is almost
certainly what you want. For that reason, I actually like little-endian
architectures.
The PDP-11 was a little peculiar in that it stored bytes in words
big-endian, but if it was using higher precision, the words were
arranged in a little endian format. So for your example:
ptr = 0x56 ( 0x5678 ) ( 0x12345678 )
+1 = 0x78
+2 = 0x12 ( 0x1234 )
+3 = 0x34
(As usual this relies on my memory functioning.)
--
Communa (lis...@zetnet.co.uk) -- you know soft spoken changes nothing
John Bayko
William Hamblen <william...@nashville.com> wrote:
>C Lamb (cs...@stoat.shef.ac.uk) wrote:
>
>: It seemed resonable to me to to have MSB at the left and LSB at the
>: you and what influences were operating on h/w designers to influence
>: the final result as big/middle/little endian?
>
The only correct format is centre-endian, where the most
significant bit is in the exact centre, and the rest are arranged in a
spiral pattern outward. This allows you to discard the sign bit -
positive numbers spiral clockwise, negative ones spiral
counterclockwise (there is only one zero, a single 0 bit in the
centre, with no spiral).
--
John Bayko (Tau).
ba...@cs.uregina.ca
http://www.cs.uregina.ca/~bayko
Richard Lamb
Shame on you.
Intel is now trying to implement that BS on the next Pentium!
Donald Tees
the shift instructions. Not only do you need a shift left
and a shift right, but you also need a shift inwards and
a shift outwards. Cpu's with that sort of built in shiftiness
tend to be problematic on overflow. The shift inwards,
of course, is the biggest problem. You can get overflow
left, overflow right, and overflow both. Rotate instructions
work out rather better, though they can result in the
programmer going cross-eyed.
John Bayko wrote in message <768m5f$stk$1...@sue.cc.uregina.ca>...
Robert Billing
> The PDP-11 was a little peculiar in that it stored bytes in words
> big-endian, but if it was using higher precision, the words were
> arranged in a little endian format. So for your example:
> ptr = 0x56 ( 0x5678 ) ( 0x12345678 )
> +1 = 0x78
> +2 = 0x12 ( 0x1234 )
> +3 = 0x34
Not Quite. The LSB of the first word is at address 0 and so on.
However there is something about this in Vol2 of Knuth IIRC. It's an
oddity of the way we write numbers that the direction in which we write
the digits is opposite to the direction in which we propagate the
carries, a blunder which no previous civilisation has made (there are
well documented historical reasons for the blunder). Because of this
there is a tension between writing MSB first, so that it looks like the
way we always write numbers, and LSB first, so that carries propagate in
the direction of increasing address.
A side effect of this is that on a little endian machine
long X ;
short * Y ;
X = 3 ;
Y = (short *) &X ;
printf ( "%d\n", *Y ) ;
will print 3 and on a big-endian machine it will print 0. This sometimes
can produce weird results when porting between different processors.
--
I am Robert Billing, Christian, inventor, traveller, cook and animal
lover, I live near 0:46W 51:22N. http://www.tnglwood.demon.co.uk/
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
John Savard
>Obviously this wasn't so for others so, which was natural for
>you and what influences were operating on h/w designers to influence
>the final result as big/middle/little endian?
Certainly, it is natural for English speakers to expect to encounter
the most significant part of a number first when proceeding through a
computer's memory in the same direction as one does to go from the
start to the end of a character string.
Arabic is written from right to left, but numbers still have their
most significant digit on the right, and so from that viewpoint, the
"little-endian" convention of the 6502, the PDP-11, and the 8086 would
seem natural.
But that isn't the reason some computers were little-endian.
Essentially, the little-endian convention started with inexpensive
minicomputers. These computers had short word lengths, and often
needed to do arithmetic on integers that were twice as long as the
computer's word length.
Since this was an add-on feature, an afterthought, instead of adding
circuitry to the computer so that when fetching the doubleword at
address n, word n+1 would be fetched first, then word n, since when
doing addition one starts with the least significant part, and then
carries, the designers of many minicomputers thought nothing of
putting the most significant word after the least significant one.
Then, along came the PDP-11, where it was thought to keep things
consistent by reversing the order in which 8-bit characters were
stored in a 16-bit word, and the "little-endian" option became fully
fleshed out. Since early versions of Unix ran on the PDP-11, it was
quite an influential computer.
The IBM 360 was an example of a pure "big-endian" computer. Even the
floating-point format used a hexadecimal exponent, making it possible
to figure out the value of a floating-point number from a hex dump.
Even the bits of a word were numbered from 0 to 31, bit 0 being the
most significant. The 68000 and the TI 9900 were also big-endian. Part
of this comes down to whether or not it's worth a little extra
hardware or microcode to make the computer easier to program in
assembly language.
Bit numbering of data lines, in a microprocessor system where one
might hook up a 12-bit ADC to a microprocessor with a 16-bit data bus,
is one argument for another aspect of the little-endian convention;
the units bit is always bit 1 if one numbers the bits starting with 1
from the least significant bit.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
Neil Franklin
>
> On 1998-12-27 cs...@stoat.shef.ac.uk said:
> :used to program on 6502 and if I wanted to represent a 32 bit
> :number I would do it so:
> :num=0x12345678
> :at address 00 value 0x12
> :at address 01 value 0x34
> :at address 02 value 0x56
> :at address 03 value 0x78
Nope. The 6502 allways wants the least significant byte first. A
snippet direct from the Commodore C64 (6502) Basic ROM listing (from
the keyboard drivers interrupt handler):
EB71 BD 7A EB LDA $EB7A,X
EB74 85 F6 STA $F6
EB76 4C E0 EA JMP $EAE0
EB79 here comes the key code to ASCII (o.k. PETSCII) table
> Erm, maybe so, but in its addressing the 6502 was little-endian.
Yes. Both little endian byte ordering (see above) and bit ordering.
> some circumstances it didn't even bother incrementing the high word of a
> pointer for indirection
Exactly one instance, the jump indirect instruction, JMP ($xxyy), 6C yy xx.
This fetches the 3 bytes of instruction code normally, then it fetches
the 2 bytes xxyy points to (aabb). Doing this it fetches bb and then
increments only yy and forgets to carry over to xx. So for the special
case of 6C FF xx you get aa from 255 lower, not 1 higher.
> though that was a bug and got fixed.)
AFAIK that was never corrected (that would make the corrected processors
incompatible with software that knows about this "feature"). Note that
this is documented behaviour (in the official MOS Technology processor
manual). But what klutz tries to missalignedly place an 16 bit pointer
in xxFF and (xx+1)(00) anyway? :-) (Yes, I know its 8 bit RAM).
> course, since it lacked any concept of double-precision arithmetic you
> could use whichever endianness you preferred.
Erm. 16 bit addresses are double precision for an 8 bit processor :-).
And the 6502 has explicit little endian byte ordereing wired into it
becuase of this. As for bit endianness, the hardware has no idea of
this, but the docu uses little endian.
On the Z80 (and 8080, and 80x86) it is the same (both bits and bytes
little endian), but both bytes and bits are wired into hardware (bytes
into all 16 bit addresses auch as LD HL, bits into all BIT/SET/RES
instructions).
> The 6800 was big-endian,
> as were (I believe) all of the Motorola processors.
AFAIK the Motorolas use an mixage of big endian byte ordering and
little endian bit ordering! At least the 6809 definitely does.
Bytes are big endian, as wired into the chip. A snippet from the
Dragon 32 (6809) Basic ROM listing (same piece of code):
BC7D 8E BC 84 LDX #$BC84
BC80 A6 86 LDA A,X
BC82 20 E4 BRA $BC68
BC84 here comes the key code to ASCII table
But bits are little endian (documentation only, nothing in hardware)
as in the official Motorola processor datasheet description of the
ASL/ASR instructions.
On the 680x0 the bits are documented little endian, but the instructions
use both little endian (single bit manipulation within an byte, there
since the 68000) and big endian (bitfield manipulation in an long
word, only added later)!
> :It seemed resonable to me to to have MSB at the left and LSB at the
> :right. Obviously this wasn't so for others so, which was natural for
> :you and what influences were operating on h/w designers to influence
> :the final result as big/middle/little endian?
As I grew up on 8 bit microprocessors (where little endian is the
norm) I regard this as logical. Both for bytes (carry) and for bits
(bit x has value of 2^x).
OTOH the big iron guys seem to all have bits and bytes big endian (at
least all PDPs before the 11), so they will regard that as more logical.
> concerned with reading numbers as with adding them, and like us, they
> add from the LSB; if you use a little-endian architecture you can
> increment a pointer through your "digits". Useful for a
> microprogrammer.
At least if faced with double precision arithmetic, as in an 6502 or
Z80 doing 16 bit address calculations. The 6809 pays dearly for being
big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full 8 cycles.
Most likely why the Dragon never uses 16bit+Register addressing.
--
Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic
ne...@franklin.ch.remove http://neil.franklin.ch/
Programming: when you stop hammering around on the computer as if it
were a piece of dumb matter and instead tell it what to do for you
Ron Hunsinger
Veken) wrote:
> Take for example an N-[byte|word|whatever] addition routine, that
> takes N and 2 pointers to the values as arguments.
> Try to write it for little-, and for big-endian machines, and
> compare the code length (and execution time).
You're making some assumptions here. For one, you're assuming that the
address of an integer is the address of its leftmost digit (that is, the
digit at the lowest address). The problem you describe only manifests
itself when the address of the integer is the address of the MSB (whichever
side that's on).
For example, the IBM 1620 was big-endian, but integers were addressed from
the LSB (highest address) end. The addition algorithm worked down from
there through lower addresses.
And that suggests a more general way to handle big-endian even if
addressing the MSB. If you know the length ahead of time, you only need to
add that to the address you're given to get the LSB address (plus one), and
use the intuitive algorithm from there. As long as you know the operand
sizes going in, there's no big performance difference between big- and
little-endian.
(Of course, that wouldn't have worked on the 1620. The MSB was recognized
by having a flag over it. You couldn't determine the length of a number
ahead of time without scanning it, a digit at a time.)
But doing arithmetic from the MSB end isn't all that hard, either. It's a
little tricky, and seems awkward since it's not the way we learned to do it
in school, but it's definitely doable.
In fact, the Burroughs Medium Systems computers (now the Unisys V-series)
does just that. It's a big-endian decimal architecture where everything
(strings, integers, and instructions) is addressed from the MSB (low
address). Operands are all variable length, with the lengths (1 to 100)
being specified in the instruction itself.
As it adds numbers, it postpones storing any digit of the result until it
learns if there will be a carry into it. To do that, it needs only two
internal registers. One holds the last non-9 result digit, assuming no
carry, and the other counts the number of 9s following it, still assuming
no carry. Once you detect a pair of summand digits whose sum is not 9, you
know what to do with everything to the left. If you have a carry, store the
saved non-9 digit plus one, then store as many zeroes as you've counted
nines. Otherwise, store the saved non-9 digit as is, followed by the
indicated number of nines.
The virtue of this is that you can detect overflow before modifying the
result. That was very important for the Medium Systems computers, whose
architecture had a frightening level of compatibility with COBOL. In COBOL,
if you say:
ADD A TO B ON OVERFLOW ...do something... .
then, if there is an overflow, you are guaranteed by the language that B
has not been modified. The way arithmetic worked on the Med.Sys. computers
made that easy to implement.
(If you don't say "ON OVERFLOW", the language allows the compiler to do
anything it wants with overflow. In this case, the compiler followed the
hardware's lead, and left B unchanged. This could surprise people coming
from other platforms, who expected overflow to do modular arithmetic.)
One thing that becomes apparent if you work a lot on big-endian computers
is that numeric comparisons become much easier if you address numbers by
their MSB. You can often tell which of two numbers is bigger without having
to examine them completely. You only have to scan down to the first
difference. This is the same way we compare strings, which are always
addressed by their MSB, even on little-endian machines.
(Of course, my previous comment that, if the length is known ahead of time,
it's trivial to convert between the MSB and LSB addresses on any
architecture, now applies in reverse.)
Still, I like the idea that big-endian numbers are stored the same way as
strings, and compared the same way.
-Ron Hunsinger
Gene Wirchenko
[snip]
>Bit numbering of data lines, in a microprocessor system where one
>might hook up a 12-bit ADC to a microprocessor with a 16-bit data bus,
>is one argument for another aspect of the little-endian convention;
>the units bit is always bit 1 if one numbers the bits starting with 1
>from the least significant bit.
IBM's standard (at least, what I encountered) was that the LSB
was bit 0. This has the advantage, if dealing with integer arithmetic
or logical operations, that the bit number is the same as the power of
two that the bit is for.
Sincerely,
gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
lis...@zetnet.co.uk
On 1998-12-29 uncl...@tnglwood.demon.co.uk said:
:lis...@zetnet.co.uk wrote:
:> The PDP-11 was a little peculiar in that it stored bytes in words
:> big-endian, but if it was using higher precision, the words were
:> arranged in a little endian format. So for your example:
:> ptr = 0x56 ( 0x5678 ) ( 0x12345678 )
:> +1 = 0x78
:> +2 = 0x12 ( 0x1234 )
:> +3 = 0x34
:Not Quite. The LSB of the first word is at address 0 and so on.
Oh. Well, this was second-hand from a magazine (Computer Shopper, back
when it was a good technical read), so fair enough. But surely something
worked this way...?
:A side effect of this is that on a little endian machine
:long X ;
:short * Y ;
:X = 3 ;
:Y = (short *) &X ;
:printf ( "%d\n", *Y ) ;
:will print 3 and on a big-endian machine it will print 0. This
:sometimes can produce weird results when porting between different
:processors.
(Isn't that what I said?)
lis...@zetnet.co.uk
On 1998-12-29 ne...@franklin.ch.remove said:
:lis...@zetnet.co.uk writes:
:> On 1998-12-27 cs...@stoat.shef.ac.uk said:
:> :used to program on 6502 and if I wanted to represent a 32 bit
:> :number I would do it so:
[big-endianly]
:Nope. The 6502 allways wants the least significant byte first.
He said that was the way *he* used to do it. Aside from the fact that
you have to make the pointers walk the number backwards for multiple
precision arithmetic, I doubt there's much in it.
:> Erm, maybe so, but in its addressing the 6502 was little-endian.
:Yes. Both little endian byte ordering (see above) and bit ordering.
Usually bit ordering doesn't matter - usually being when you don't have
bit or bitfield instructions. I've never used one in my life, so...
:> some circumstances it didn't even bother incrementing the high
:>word of a pointer for indirection
:Exactly one instance, the jump indirect instruction, JMP ($xxyy),
:6C yy xx.
I forgot which. Thanks.
:> though that was a bug and got fixed.)
:AFAIK that was never corrected (that would make the corrected
:processors incompatible with software that knows about this
:"feature").
Didn't the 65C02 correct it, as well as adding all kinds of other useful
instructions? I'm pretty sure the 65C802/816 did.
:> course, since it lacked any concept of double-precision
:> arithmetic you could use whichever endianness you preferred.
:Erm. 16 bit addresses are double precision for an 8 bit processor
::-).
OK, when you show me the single 6502 instruction to add two 16-bit
quantities I'll believe you. Note the key word "arithmetic". A 6502
without double precision support at all would be, erm, a bit sad...
:> The 6800 was big-endian,
:> as were (I believe) all of the Motorola processors.
:AFAIK the Motorolas use an mixage of big endian byte ordering and
:little endian bit ordering! At least the 6809 definitely does.
I thought the question of endianness primarily related to bytes...?
:On the 680x0 the bits are documented little endian, but the
:instructions use both little endian (single bit manipulation within
:an byte, there since the 68000) and big endian (bitfield
:manipulation in an long word, only added later)!
I guess that counts as a "feature"... What of the 88x00 and PowerPC? Do
they swap at will?
:> concerned with reading numbers as with adding them, and like us,
:> they add from the LSB; if you use a little-endian architecture
:> you can increment a pointer through your "digits". Useful for a
:> microprogrammer.
:At least if faced with double precision arithmetic, as in an 6502 or
:Z80 doing 16 bit address calculations. The 6809 pays dearly for
:being big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full
:8 cycles. Most likely why the Dragon never uses 16bit+Register
:addressing.
Ouch! (Although since even 8 cycles would have been faster than the
alternative, it's quite conceivable that they would just not have needed
to use an offset bigger than 8 bits.)
lis...@zetnet.co.uk
On 1998-12-29 jsa...@tenMAPSONeerf.edmonton.ab.ca(JohnSavard) said:
:The IBM 360 was an example of a pure "big-endian" computer. Even the
:floating-point format used a hexadecimal exponent, making it
:possible to figure out the value of a floating-point number from a
:hex dump. Even the bits of a word were numbered from 0 to 31, bit 0
:being the most significant. The 68000 and the TI 9900 were also
:big-endian. Part of this comes down to whether or not it's worth a
:little extra hardware or microcode to make the computer easier to
:program in assembly language.
In my experience of debugging at the machine code level on an x86, you
do get used to flipping the bytes yourself after reading (far) too many
stack dumps...
Andrew Gabriel
ge...@vip.net (Gene Wirchenko) writes:
>
> IBM's standard (at least, what I encountered) was that the LSB
>was bit 0.
I'm pretty sure the IBM 360 had MSB as bit 0.
However, if I'm wrong, I'm sure someone will be along to correct
me shortly...
--
Andrew Gabriel
Consultant Software Engineer
Neil Franklin
>
> On 1998-12-29 ne...@franklin.ch.remove said:
>
> :Yes. Both little endian byte ordering (see above) and bit ordering.
>
> Usually bit ordering doesn't matter - usually being when you don't have
> bit or bitfield instructions. I've never used one in my life, so...
But as soon as the processor has bit instructions (Z80, 80x8x, 680x0)
then it does count. Even if one never uses them (I never did either).
> :> though that was a bug and got fixed.)
>
> :AFAIK that was never corrected (that would make the corrected
> :processors incompatible with software that knows about this
> :"feature").
>
> Didn't the 65C02 correct it, as well as adding all kinds of other useful
> instructions? I'm pretty sure the 65C802/816 did.
That is possible. I had left the 8 bit world by then (hello 80286).
But being incompatible on 1/4 of newly added instructions (C0..FF?)
sure makes this change harmless.
> :> course, since it lacked any concept of double-precision
> :> arithmetic you could use whichever endianness you preferred.
>
> :Erm. 16 bit addresses are double precision for an 8 bit processor
> ::-).
>
> OK, when you show me the single 6502 instruction to add two 16-bit
> quantities I'll believe you. Note the key word "arithmetic".
Will adding an 16 bit and an unsigned extended 8 bit do? If so:
STA $aabb,X adds an 16 bit (aabb) and an zero-extended 8 bit (00XX)
to form the effective address to store A into. That _is_ known as
address arithmetic :-). And it is in double precision. And it dictates
arangement, making the 6502 hardwarily little endian.
O.K. I am stretching it a bit. <gd&r>
> A 6502
> without double precision support at all would be, erm, a bit sad...
Not just support (the carry flag) but actual instruction using dual
precision (at least as far as the address arithmetic part goes).
> :> The 6800 was big-endian,
> :> as were (I believe) all of the Motorola processors.
>
> :AFAIK the Motorolas use an mixage of big endian byte ordering and
> :little endian bit ordering! At least the 6809 definitely does.
>
> I thought the question of endianness primarily related to bytes...?
There are 2 separate endiennesses, bit and byte. Usually the same
(big/little), which is why many do not recognize them to be 2 things.
680x0 makes the distinction neccessary.
> :instructions use both little endian (single bit manipulation within
> :an byte, there since the 68000) and big endian (bitfield
> :manipulation in an long word, only added later)!
>
> I guess that counts as a "feature"... What of the 88x00 and PowerPC? Do
> they swap at will?
I have never looked at their instruction formats in that detail. I
would assume that Motorola has learned its lesson before making the
88x00. And the PPC was defined by IBM anyway, so most likely full big
endian.
> :At least if faced with double precision arithmetic, as in an 6502 or
> :Z80 doing 16 bit address calculations. The 6809 pays dearly for
> :being big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full
> :8 cycles. Most likely why the Dragon never uses 16bit+Register
> :addressing.
>
> Ouch! (Although since even 8 cycles would have been faster than the
> alternative, it's quite conceivable that they would just not have needed
> to use an offset bigger than 8 bits.)
Well the code I was looking at, which required an 16 bit base with
variable offset (analog to 6502 LDA $xxxx,X), does the alternative:
it uses 2 instructions, LDU xxxx and then LDA A,U.
C Lamb
: Didn't the 65C02 correct it, as well as adding all kinds of other useful
: instructions? I'm pretty sure the 65C802/816 did.
I had a manual for the 6502/65C02 and among the extra instructions
were a set of 8 BBS (branch on bit set) instructions
: :> course, since it lacked any concept of double-precision
: :> arithmetic you could use whichever endianness you preferred.
: :Erm. 16 bit addresses are double precision for an 8 bit processor
: ::-).
: OK, when you show me the single 6502 instruction to add two 16-bit
: quantities I'll believe you. Note the key word "arithmetic". A 6502
: without double precision support at all would be, erm, a bit sad...
exactamundo, I was trying to beat the BBC micros own draw line algo
so I needed 16 bit addition and I went on to produce 32bit add, mul,
sub and the biggie, divide (I don't know why but I was very proud
getting it all by shift and subtracts rather than repeated subs.
Well, I was rather young at the time (~15yrs))
Oh, and I *never* beat the BBC micro for drawing lines. Which brings
me onto the unusual method it had for addressing the screen in
hi-res(2 colours), rather than a raster like display the first
byte was 8 pixels @ topleft corner but the second byte represented the 8
pixels below it, the following 6 bytes below that, then the 9th byte
represented the 9th to 16th pixels to the right of the 1st byte,
a load of mini columns across the screen. Made text display really
fast but addressing the screen in graphics a complete cow.
regards
C
Charlie Gibbs
What's this?
8080
8086
8088
80186
80286
80386
80386SX
80486
80486SX
Pentium
Ten little-endians!
(One little, two little, three little Intels...)
--
cgi...@sky.bus.com (Charlie Gibbs)
Remove the first period after the "at" sign to reply.
tur...@my-dejanews.com
> exactamundo, I was trying to beat the BBC micros own draw line algo
> so I needed 16 bit addition and I went on to produce 32bit add, mul,
you need 16 bit addition to do a line draw? What computer were you using?
> Oh, and I *never* beat the BBC micro for drawing lines. Which brings
> me onto the unusual method it had for addressing the screen in
> hi-res(2 colours), rather than a raster like display the first
> byte was 8 pixels @ topleft corner but the second byte represented the 8
> pixels below it, the following 6 bytes below that, then the 9th byte
> represented the 9th to 16th pixels to the right of the 1st byte,
> a load of mini columns across the screen. Made text display really
> fast but addressing the screen in graphics a complete cow.
Actually, this was a rather usual method for many computers, particularly
those based on a 6845 or similar address and timing generator. The
architecture made it easy to implement text mode by reading the character
definition from an appropriate ROM or RAM. Graphics, which was less
frequently used, was an added bonus. The beeb and (I believe) CGA and
Hercules boards for peecees used 6845s and had this quaint graphics
addressing. The Commodore 64 did too, for the same reasons, but using their
own VIC II chip. And so did my first home-brew computer which used a 6845
;-)
Graphics addressing quirk aside, I really liked the 6845 as it was a simple
yet very flexible design. You could put program the address generators and
timers to set the screen to whatever size you liked and get rid of the "fixed
border" that you got on personal computers of the day. It had an interlace
mode for "bonus" resolution if you had the graphics memory. It had a
"half-scan" mode where odd frames were offset by half a scan line to give a
"smoother" look just like a tv, providing you had a reasonably persistent
monitor. Raster interrupts were easy to implement with an external counter
and (I think) it had an internal light pen counter.
Of course, I'm romanticising somewhat ;-) Back in those days every cycle I
could save coding graphics routines on my Commodore 64 counted and I hated
that graphics addressing format... :-)
-t.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
tur...@my-dejanews.com
"Charlie Gibbs" <cgi...@sky.bus.com> wrote:
> Things are getting way too serious here...
>
> What's this?
>
> 8080
> 8086
> 8088
> 80186
> 80286
> 80386
> 80386SX
> 80486
> 80486SX
> Pentium
>
> Ten little-endians!
... and they're all junk :-)
Kin Hoong CHUNG
: I have never looked at their instruction formats in that detail. I
: would assume that Motorola has learned its lesson before making the
: 88x00. And the PPC was defined by IBM anyway, so most likely full big
: endian.
The PPC (according to the Moto WWW site) is big-endian, with a
little-endian option. It is also now both 64-bit and 32-bit,
with segments available only in 32-bit mode (:-( if you like Multics).
:> :At least if faced with double precision arithmetic, as in an 6502 or
:> :Z80 doing 16 bit address calculations. The 6809 pays dearly for
:> :being big endian, LDA $xx,U needs 5 cycles, LDA $xxxx,U needs full
:> :8 cycles. Most likely why the Dragon never uses 16bit+Register
:> :addressing.
: Well the code I was looking at, which required an 16 bit base with
: variable offset (analog to 6502 LDA $xxxx,X), does the alternative:
: it uses 2 instructions, LDU xxxx and then LDA A,U.
Well, the 6809 was not designed with speed as the primary concern, and it
was certainly not designed with RISC principles. One often needed to
look at the instruction timing to maximise the speed (for example CLR A
is preferred to LDA #0). The most irritating part of it was the lack of
registers... the number of times people perform TFR D,X to avoid an
expensive register-memory operation is quite high. Still, it had its
niceties, like a 6-cycle multiply (pity it only worked on 8-bits and used
both the A and B registers) and position independent code (again with the
irritating choice between a quick BRA +8-bit argument and the slower
LBRA +16-bit argument for PC-relative branches).
Cheers,
Kin Hoong
Joseph M. Newcomer
was to put the LSD on the left, going to the right to the MSD. For
example, it made them easy to type because you didn't have to figure
out how many spaces had to precede the number so that the LSDs all
lined up. He not only asserted this, he actually wrote his numbers
that way. This made it awkward because when he was lecturing he would
often write numbers in his inverted order and confuse his audience.
joe
On Tue, 29 Dec 1998 19:08:35 GMT, jsa...@tenMAPSONeerf.edmonton.ab.ca
(John Savard) wrote:
>cs...@stoat.shef.ac.uk (C Lamb) wrote, in part:
>
>>Obviously this wasn't so for others so, which was natural for
>>you and what influences were operating on h/w designers to influence
>>the final result as big/middle/little endian?
>
>Certainly, it is natural for English speakers to expect to encounter
>the most significant part of a number first when proceeding through a
>computer's memory in the same direction as one does to go from the
>start to the end of a character string.
>
>Arabic is written from right to left, but numbers still have their
>most significant digit on the right, and so from that viewpoint, the
>"little-endian" convention of the 6502, the PDP-11, and the 8086 would
>seem natural.
>
>But that isn't the reason some computers were little-endian.
>
>Essentially, the little-endian convention started with inexpensive
>minicomputers. These computers had short word lengths, and often
>needed to do arithmetic on integers that were twice as long as the
>computer's word length.
>
>Since this was an add-on feature, an afterthought, instead of adding
>circuitry to the computer so that when fetching the doubleword at
>address n, word n+1 would be fetched first, then word n, since when
>doing addition one starts with the least significant part, and then
>carries, the designers of many minicomputers thought nothing of
>putting the most significant word after the least significant one.
>
>Then, along came the PDP-11, where it was thought to keep things
>consistent by reversing the order in which 8-bit characters were
>stored in a 16-bit word, and the "little-endian" option became fully
>fleshed out. Since early versions of Unix ran on the PDP-11, it was
>quite an influential computer.
>
>The IBM 360 was an example of a pure "big-endian" computer. Even the
>floating-point format used a hexadecimal exponent, making it possible
>to figure out the value of a floating-point number from a hex dump.
>Even the bits of a word were numbered from 0 to 31, bit 0 being the
>most significant. The 68000 and the TI 9900 were also big-endian. Part
>of this comes down to whether or not it's worth a little extra
>hardware or microcode to make the computer easier to program in
>assembly language.
>
>Bit numbering of data lines, in a microprocessor system where one
>might hook up a 12-bit ADC to a microprocessor with a 16-bit data bus,
>is one argument for another aspect of the little-endian convention;
>the units bit is always bit 1 if one numbers the bits starting with 1
>from the least significant bit.
>
>John Savard
>http://www.freenet.edmonton.ab.ca/~jsavard/index.html
Joseph M. Newcomer
newc...@flounder.com
http://www3.pgh.net/~newcomer
lis...@zetnet.co.uk
On 1998-12-30 ne...@franklin.ch.remove said:
:> Usually bit ordering doesn't matter - usually being when you
:> don't have bit or bitfield instructions. I've never used one in
:> my life, so...
:But as soon as the processor has bit instructions (Z80, 80x8x,
:680x0) then it does count. Even if one never uses them (I never did
:either).
Surely not if one never uses them, it doesn't - unless someone else does
and you're debugging it, but I was assuming this case came under "not one's
own doing". I don't know or care which end of the x86 word is bit 0 and
which is bit 7, precisely because I never use those instructions. (x > 2)
:> Didn't the 65C02 correct it, as well as adding all kinds of other
:>useful instructions? I'm pretty sure the 65C802/816 did.
:That is possible. I had left the 8 bit world by then (hello 80286).
:But being incompatible on 1/4 of newly added instructions (C0..FF?)
:sure makes this change harmless.
Depends whether the instructions were no-ops before; well-behaved 6502
programs wouldn't have used the undocumented instructions. That's the point
of upward compatibility. And as you said, most programmers would not have
used it as a feature, they just would have word aligned their pointers.
:> OK, when you show me the single 6502 instruction to add two 16-bit
:> quantities I'll believe you. Note the key word "arithmetic".
:Will adding an 16 bit and an unsigned extended 8 bit do? If so:
Explicitly not! ;>
:STA $aabb,X adds an 16 bit (aabb) and an zero-extended 8 bit (00XX)
:to form the effective address to store A into. That _is_ known as
:address arithmetic :-). And it is in double precision. And it
It shouldn't be; it's indexing. I'd believe it to be address arithmetic if
you had an LEA instruction... And it's mixed precision, so there. :P
:dictates arangement, making the 6502 hardwarily little endian.
Agreed. (Though it wouldn't surprise me to find somewhere where addresses
and data were kept in a different endian-ness.)
:O.K. I am stretching it a bit. <gd&r>
<throws a 65C02 at you>
:> Ouch! (Although since even 8 cycles would have been faster than
:> the alternative, it's quite conceivable that they would just not
:> have needed to use an offset bigger than 8 bits.)
:Well the code I was looking at, which required an 16 bit base with
:variable offset (analog to 6502 LDA $xxxx,X), does the alternative:
:it uses 2 instructions, LDU xxxx and then LDA A,U.
Strange. What's the cycle count of that? (They may just not have known, or
had a compiler that didn't know, about the longer variant.)