gd@geovision.uucp (Gord Deinstadt) (06/02/89)
In article <1989May30.171335.473@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > >Just to be heretical, one can observe that the same thing is true of >addresses. You can run the 68k family with 16-bit addresses (although >they have to be *signed* 16-bit addresses!). Can anyone tell my why Motorola did such a twisted, sick thing? Gord Deinstadt gd@geovision.uucp
henry@utzoo.uucp (Henry Spencer) (06/04/89)
In article <658@geovision.UUCP> gd@geovision.UUCP (Gord Deinstadt) writes: >>... You can run the 68k family with 16-bit addresses (although >>they have to be *signed* 16-bit addresses!). > >Can anyone tell my why Motorola did such a twisted, sick thing? For much the same reason Intel gave us segments, but from the other side of the fence: it was a time of transition past the 16-bit boundary, with nobody wanting to stay with a pure 16-bit solution but many customers resisting going to a pure 32-bit solution. Intel wanted bigger addresses but didn't want to enlarge registers etc., so we got segments. Motorola originally started out with 16-bit data but larger addresses -- which is why the A/D register split in the 68k -- but relatively late in design they went 32 most places. However, they wanted to preserve the ability for people to work in a 16-bit world, with only two bytes needed to store an address and only one fetch needed to get one across a 16-bit bus. So pretty well all the A-register manipulation instructions have variants that only work with the bottom 16 bits. They sign-extend, which is why the addresses are signed. We'll probably see the same approaches again when people start seriously contemplating the 32-bit boundary. -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
slackey@bbn.com (Stan Lackey) (06/06/89)
In article <658@geovision.UUCP> gd@geovision.UUCP (Gord Deinstadt) writes: >In article <1989May30.171335.473@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >> >>Just to be heretical, one can observe that the same thing is true of >>addresses. You can run the 68k family with 16-bit addresses (although >>they have to be *signed* 16-bit addresses!). > >Can anyone tell my why Motorola did such a twisted, sick thing? I suspect that the reason 16-bit absolute addresses are signed is because all instruction stream data is sign extended, and the designers figured that 32Kbytes of scalar addressing was enough anyway, so why make an exception for addresses. The reason for the 16-bit absolute addressing mode was because in 1977? when the 68000 was designed, 1) people cared about the amount of memory their application needed, and 2) lots and lots of applications used less than 32K bytes for scalar data. Also, it read the instruction stream in 16-bit hunks, and a 16-bit quantity took only one memory cycle whereas a full 32-bit address would take two. The 68000 was the next generation after the 6800/6809 8-bitters, and was influenced much by the embedded controller market. Here, the program was typically in ROM, and only data was in RAM. I would bet that Motorola was pleasantly surprised by how well the chip caught on in the (then nonexistant) workstation business. I feel that including 32-bit features at all showed great insight by its designers, and I also feel that the 68000 family was partially responsible for the emergence of the workstation as a market entity. -SAL
davet@oakhill.UUCP (David Trissel) (06/06/89)
In article <40938@bbn.COM> slackey@BBN.COM (Stan Lackey) writes: >The 68000 was the next generation after the 6800/6809 8-bitters, and was >influenced much by the embedded controller market. Here, the program >was typically in ROM, and only data was in RAM. I would bet that >Motorola was pleasantly surprised by how well the chip caught on in >the (then nonexistant) workstation business. Good guess. I remember a group of us at the plant talking among ourselves and wondering if any customers would even want something like a MC68000. Hard to believe now, isn't it? But remember, at that time not even the MC6809 had been introduced and our largest systems were MC6800 with a whopping 16K of RAM. You were really a bigwig if your MC6800 system had 24K or (GASP!) 32K of RAM. The sign-extended short absolute addressing was deemed to be a perfect fit for hardware designers chosing to put the I/O ports at the "upper" end of memory since this was typical of hardware designs with the 16-bit bus processors. Of historical interest is a seminar I gave on the just-announced MC68000 in Toronto. I mentioned that a 10 Mhz MC68000 would run at nearly a full MIP and I was actually hissed at by some of the crowd. To many of them it was simply absurd to think that a microprocessor could attain such speed. -- Dave Trissel - Motorola Semiconductor Inc. - Austin
gd@geovision.uucp (Gord Deinstadt) (06/07/89)
In article <40938@bbn.COM> slackey@BBN.COM (Stan Lackey) writes: >In article <658@geovision.UUCP> gd@geovision.UUCP (Gord Deinstadt) writes: >>In article <1989May30.171335.473@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>> >>>Just to be heretical, one can observe that the same thing is true of >>>addresses. You can run the 68k family with 16-bit addresses (although >>>they have to be *signed* 16-bit addresses!). >> >>Can anyone tell my why Motorola did such a twisted, sick thing? > >I suspect that the reason 16-bit absolute addresses are signed is >because all instruction stream data is sign extended, and the >designers figured that 32Kbytes of scalar addressing was enough >anyway, so why make an exception for addresses. I suspect that's it. From Henry Spencer's follow-up, it seems the intent was that all your pointers would be 32-bit, and offsets would likely only be used for accessing fields within a structure and perhaps local variables off the frame pointer. Someone also pointed out via e-mail that you can use the 16-bit absolute mode for easy addressing into either very high or very low memory. This is handy because very low mem contains interrupt vectors and the like, and i/o is usually mapped into very high mem. Actually, I don't mind the absolute addresses being signed; it's a fairly minor issue. It's the signed offsets in base+offset mode that burn me up. You *can* work around it (ie. still get a 64k address range with 16-bit offsets) by fudging all your base addresses by 32768; but you shouldn't have to. Especially considering that this was in the days when people still wrote a lot of assembler. (Gosh, did people actually do that when I was young? ;-P) >The reason for the 16-bit absolute addressing mode was because in >1977? when the 68000 was designed, 1) people cared about the amount of >memory their application needed, and 2) lots and lots of applications >used less than 32K bytes for scalar data. And of course Intel was going around bragging about how compact 8086 code was. >I feel that including 32-bit features at all showed great insight by >its designers, and I also feel that the 68000 family was partially >responsible for the emergence of the workstation as a market entity. No argument about that from here. I like the 68000, generally, and often chafe at having to use 8086-family machines for the "wrong" reasons. My admiration for the 68000 only adds to my disappointment at what I consider to be a flaw in the architecture. Gord "an unsigned for the times" Deinstadt
quiroz@cs.rochester.edu (Cesar Quiroz) (06/09/89)
In <660@geovision.UUCP>, gd@geovision.UUCP (Gord Deinstadt) wrote: | ... | Actually, I don't mind the absolute addresses being signed; it's a | fairly minor issue. It's the signed offsets in base+offset mode that | burn me up. You *can* work around it (ie. still get a 64k address | range with 16-bit offsets) by fudging all your | base addresses by 32768; but you shouldn't have to. Especially | considering that this was in the days when people still wrote | a lot of assembler. (Gosh, did people actually do that when | I was young? ;-P) You would be surprised... In a former life I did some System 370 assembly, and one of the most common complaints was that literal offsets went only forwards (4K?). A properly twisted mind will pass you addresses in the middle of some structure and hope you know what you are doing. (There may have been also some trouble when writing macros wherein one would branch to a lower address that you forgot to label, but I am now blissfully ignorant of the macro assembler, so this recollection is likely to be bogus.) So signed vs unsigned offsets seems to be a judgment call, you will make some people unhappy either way. Also, we are talking here offsets of 32K before you see the difference, probably not such a frequent problem any way. -- Cesar Augusto Quiroz Gonzalez Department of Computer Science University of Rochester Rochester, NY 14627
hammondr@sunroof.crd.ge.com (richard a hammond) (06/09/89)
In <660@geovision.UUCP>, gd@geovision.UUCP (Gord Deinstadt) wrote: > ... > Actually, I don't mind the absolute addresses being signed; it's a > fairly minor issue. It's the signed offsets in base+offset mode that > burn me up. You *can* work around it (ie. still get a 64k address > range with 16-bit offsets) by fudging all your > base addresses by 32768; but you shouldn't have to. Especially > considering that this was in the days when people still wrote > a lot of assembler. (Gosh, did people actually do that when > I was young? ;-P) But, read the processor's User Manual for the LINK instruction, the instruction which one would normally use to adjust a frame pointer. "A negative displacement is specified to allocate stack area." Hence, all your local, dynamic variables would be at negative offsets from the frame pointer, while incoming arguments to the subroutine would be at positive offsets from the frame pointer. While this might not be all that important for the assembly language programmer, it made porting the portable C compiler (and thus UNIX) easy. Rich Hammond
boyne@hplvli.HP.COM (Art Boyne) (06/09/89)
gd@geovision.uucp (Gord Deinstadt) writes: >Actually, I don't mind the absolute addresses being signed; it's a >fairly minor issue. It's the signed offsets in base+offset mode that >burn me up. You *can* work around it (ie. still get a 64k address >range with 16-bit offsets) by fudging all your >base addresses by 32768; but you shouldn't have to. Signed offsets in address register direct with displacement mode are useful when dealing with stack frames (LINK command). Local variables are located at negative offsets from the *stack frame* pointer, parameters are at positive offsets. True, one could argue that the local variables are at positive offsets from the *stack* pointer, but it is a pain when writing assembler to remember to kludge the offsets while pushing parameters when calling another function (let's see... I've pushed a word and three longs, so I need x+14(SP), I think). It's a lot easier to use the unchanging negative offsets from the *stack frame* pointer. After writing >100K of 68000 assembler in the last 5 years, I have good reason to want the signed offsets. Yes, it means that you have to kludge to get a 64k address range, but many smaller systems don't have that much global/stack data, which is where most assembler is written. Bigger systems are written in HLL's and the compiler takes care of this automatically. :-) Art Boyne, boyne@hplvla.hp.com
peter@ficc.uu.net (Peter da Silva) (06/10/89)
In <660@geovision.UUCP>, gd@geovision.UUCP (Gord Deinstadt) wrote: | Actually, I don't mind the absolute addresses being signed; it's a | fairly minor issue. It's the signed offsets in base+offset mode that | burn me up. It's useful on occasion. For example, Amiga shared libraries have shared data at positive offsets, and a jump table at negative offsets. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
aglew@mcdurb.Urbana.Gould.COM (06/12/89)
>| Actually, I don't mind the absolute addresses being signed; it's a >| fairly minor issue. It's the signed offsets in base+offset mode that >| burn me up. > >It's useful on occasion. For example, Amiga shared libraries have shared >data at positive offsets, and a jump table at negative offsets. The 88K does not have signed offsets (except for branches). I recall (but do not have the reference handy) a paper by some fellows from Tektronix who were porting Scheme to the 88K that listed lack of signed offsets as one of the things that made their task slightly more difficult. However, lack of signed offsets certainly has not prevented LISP and other AI type languages from being ported to the 88K. Come to think of it, I have several hundred megabytes of 68K opcode traces sitting on tape somewhere - let me go and count the number of negative offsets in them.
meissner@tiktok.dg.com (Michael Meissner) (06/19/89)
In article <28200334@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes: | | >| Actually, I don't mind the absolute addresses being signed; it's a | >| fairly minor issue. It's the signed offsets in base+offset mode that | >| burn me up. | > | >It's useful on occasion. For example, Amiga shared libraries have shared | >data at positive offsets, and a jump table at negative offsets. | | The 88K does not have signed offsets (except for branches). | | I recall (but do not have the reference handy) a paper by some fellows from | Tektronix who were porting Scheme to the 88K that listed lack of signed | offsets as one of the things that made their task slightly more difficult. | However, lack of signed offsets certainly has not prevented LISP and other | AI type languages from being ported to the 88K. I don't about AI languages on the 88000, but not having negative literals was an extreme pain in finishing the GNU C 88000 port. The compiler internally expects to have a frame where local variables are on one side of the frame, and arguments' stack slots are on the other side. This certainly is my biggest gripe about the 88000, though signed division is close behind. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?
firth@sei.cmu.edu (Robert Firth) (06/22/89)
In article <7233@xyzzy.UUCP> meissner@tiktok.UUCP (Michael Meissner) writes: >I don't about AI languages on the 88000, but not having negative >literals was an extreme pain in finishing the GNU C 88000 port. The >compiler internally expects to have a frame where local variables are >on one side of the frame, and arguments' stack slots are on the other >side. Ouch! If the compiler expects that, it is making a seriously unwarranted assumption and should be fixed. As far as possible, all logically different address spaces should be maintained separately by the compiler internal phases. For example, many machines impose special size or alignment restrictions on objects passed as actuals; it is really helpful if the compiler understands the concept of a separate 'actual parameter' space with its own rules for allocation and packing. That said, I also find negative offsets helpful in many situations.