Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cuae2!ltuxa!cuuxb!mwm From: mwm@cuuxb.UUCP Newsgroups: comp.arch,comp.sys.intel,comp.sys.m68k Subject: Re: byte order: be reasonable - do it my way... Message-ID: <1011@cuuxb.UUCP> Date: Sat, 10-Jan-87 21:54:48 EST Article-I.D.: cuuxb.1011 Posted: Sat Jan 10 21:54:48 1987 Date-Received: Sun, 11-Jan-87 07:07:09 EST References: <760@orcisi.UUCP> Reply-To: mwm@cuuxb.UUCP (Marc W. Mengel) Organization: AT&T-IS, Software Support, Lisle IL Lines: 188 Xref: watmath comp.arch:184 comp.sys.intel:85 comp.sys.m68k:99 In article <760@orcisi.UUCP> urip@orcisi.UUCP writes: >My point is that the Least-Significant-Byte-first camp (LSBians, >pronounced: elesbians) has a more correct way than the Most-Significant-byte- >first (MSBians, pronounced: emesbians), and I am going to try to convince >the MSBians to go my way. >... >"Hence, the M68000 is a consistent Big-Endian, except for its bit >designation, which is used to camouflage its true identity. >Remember: the Big-Endians were the outlaws." > >The author did not try to claim that the funny floating point format >of the VAX was to camouflage the VAX's true identity, so why should one believe >that the LSBian bit order of the M68000 is because "the Big-Endians were >the outlaws" ? I suspect that the true reason behind the inconsistency >of the M68000 is the fact that only with an LSBian bit order, the value of >bit number 'i' in a word is always equal to > > b[i] * 2^i > >(where b[i] is 0 or 1 according to bit number 'i', and 2^i is 2 to the power >of i) >and the designers of M68000 wanted to keep this important feature in spite of >the overall MSBian architecture. The bit notation is strictly notational, and has no bearing on the operation of the cpu. One could go entirely through any MC68000 book and replace the bit-numbers appropriately throughout. Bit notation (what way you number which bits) has no relation to byte ordering. I could number my bits: 13579BDF2468ACE 000000000000001 to represent the number 1 if I so chose. Saying that byte ordering that proceeds in the opposite direction to bit ordering is some how "inconsistent" is part of your argument, I would maintain that it is moot. > [ long disscussion of how in LSBian machines, a movebyte 2,x and a > movelong 2,x generate the same bits at location x] > >This may not seem to be a key issue, but it has some significance in type >conversion as illustrated by the following C program segment: > >{int i; char ch; ch = i;} > >The 'int' (assume int is 32 bits) value has to be converted to 'char' or byte. >In LSBian, this conversion is just a simple 'movb' (move byte) instruction >from 'i' to 'ch': > > movb i, ch > >since both byte and long-word contain the same value. > >In MSBian it may involve an expensive bit field instruction (or worse, >shifts and ands). Luckily for the M68000, it is byte addressable, so the >compiler can do the trick and generate: > > movb i+3, ch > >So it is still a simple machine instruction, but it involves a small trick. Actually, what should be done, in general, is something similar to the VAX trick of having a conversion instruction, and do a cvt_lb i,ch Unfortunately, in the 68000 the type-conversion (sign extension/truncation) operations only work between registers, and one is forced to resort to kluges like mov.b i+3,ch in order to do the job efficiently. >Not clean, but still consistent, as long as we stick to byte addressable >memory. > >But what about registers? registers are not byte addressable. >There is only one byte of a register that can be accessed by a 'movb' >instruction. All the other 3 bytes can be accessed only through bit field >instructions (or worse, shifts and ands). This is true of big-endian and little-endian machines which are byte addressable.... >Let's look at another program segment: > > {extern int fgetc(); char ch; ch = fgetc(file);} > >The C library routine 'fgetc' returns an 'int' result and it has to be >converted to 'char'. Most implementations return function results in >register 0. > >Assume that register D0 contains 'int' (32 bits) value 2, >and so does the long-word at address 100. > > MSB in lower address > >address 100 101 102 103 104 > +----+----+----+----+ >value | 00 | 00 | 00 | 02 | > +----+----+----+----+ > +----+----+----+----+ >register D0 | 00 | 00 | 00 | 02 | > +----+----+----+----+ > >The instructions > > movl 100,x > movl D0,x > >both move a long-word containing value 0x00000002 to location 'x'. >so > movb 100,x > movb D0,x > >both should move a byte containing value 00 to locaion 'x'. Okay so far, both big endian and little endian machines do this; so long as the definition of "Location x" includes a *type*. Whether that type is a 17 bit wide field or a 1 byte wide feild, in either machine, locations need types to make them consistent. Type conversion could even be implemented to generate an exception on truncation of signifigant bits, and to sign extend appropriately. >So the code generated for above program segment in a true consistent >MSBian machine would be: > > jbsr fgets > movl 24,d1 > lsrl d1,d0 > movb d0,ch Huh? Once again you are defining "consistent" to suit your argument against MSBian machines. > >But in M68000 this is not true. No shift operation is needed because >a 'movb' instruction with a register operand takes the byte that contains 2, >that is, the HIGH address bit, so the compiler can generate a > > jbsr fgets > movb d0,ch Once again you miss the fact that the longword at location x is different from the character at location x. (This is, incidentally, a register-based type conversion, treating d0 first as a long and then as a character, as per my discussion above. The code should read: jsbr fgets cvt_lb d0,ch It just so happens that a movb on a long word *does* convert long to byte.) > >In other words, we see that the byte/word/long-word overlap of registers >in the M68000 is implemented according to the more efficient LSBian way!! > Wait a minute. First you claim that the MC68000 is MSBian, but that its *registers* are LSBian???? What does byte order in memory have to do with registers??? Are you saying that the 68000 should load bytes into the high order bits of a register rather than the low order bits in order to be "consistent"? > >Conclusion: >========== > >I have shown that there are two aspects in which the LSBian way is more >suitable and more efficent for binary computers. This is in addition >to the argument of easier serial addition and multiplication that was mentioned >in the article (though the latter is balanced, to some extent, by serial >comparison and division). > >The main argument left against the LSBians is the more readable MSBian >dump format. I think that in the modern days of optimizing compilers and >symbolic debuggers, dumps are almost an extinct species, and please >let them stay that way. > >I don't have any illusions. I don't expect Motorola to change their byte order >after reading my article. I don't even expect users to prefer LSBian >machines just for the sake of beauty and consistency. >But I do hope that some day the LSBian method will prevail (or, maybe, >someone will convince me of the superiority of the MSBian method...). > Unfortuntately that won't happen either -- the point I am trying to make is that for computational purposes, they byte-ordering question is moot. When you introduce the paradign of typed memory locations and type conversion instructions, the two systems become computationally equivalent. > >Uri Postavsky (utcs!syntron!orcisi!urip) > > (currently with O.R.C Toronto, > formerly with National Semiconductor Tel Aviv). -- Marc Mengel ...!ihnp4!cuuxb!mwm