From: rnewman@thecia.net (Ron Newman) Newsgroups: alt.folklore.computers Subject: IBM RT PC (was Re: What does AT stand for ?) Date: Tue, 08 Feb 2000 08:44:34 -0500 Organization: http://extra.newsguy.com Lines: 37 Message-ID: References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> NNTP-Posting-Host: p-766.newsdawg.com X-Newsreader: MT-NewsWatcher 2.4.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newsfeeds.belnet.be!news.belnet.be!newsfeed.direct.ca!su-news-hub1.bbnplanet.com!news.gtei.net!pln-w!spln!extra.newsguy.com!newsp.newsguy.com!rnewman Xref: chonsp.franklin.ch alt.folklore.computers:49488 In article <87p3h0$m2f$1@bcarh8ab.ca.nortel.com>, mwandel@nortel.ca (Markus Wandel) wrote: > Then there was the IBM PC/RT which was some sort of RISC machine. Actually, the correct name was "RT PC". It was not a great success, and was re-engineered and re-introduced as the RS/6000. It ran a strange flavor of Unix called "AIX". "RT" stood for "RISC Technology", and "RS" probably means "RISC System". The original RT PC had one *very* nasty misfeature, which repeatedly burned people who were trying to port software from either DEC VAXen or Intel PCs: Pointers to 4-byte entities had to be aligned on 4-byte boundaries. BUT if you violated this rule, the RT PC would not crash your program with a bus error or segmentation violation. Instead, the RT PC would silently ignore the bottom 2 bits of your 32-bit pointer, rounding it down to a 4-byte boundary! Not fun at all. I remember working at Lotus when the first RT PC arrived, and we were trying to port Lotus 1-2-3 from the Intel-based IBM PC to the RT PC. Since the Intel architecture had no alignment restrictions, the software often packed data tightly and did pointer arithmetic to advance from one data field to the next. On the RT PC, this obviously would not work, but the machine would never tell you! > I remember briefly playing with one of those when they were new, in 1986. > A GUI word processor that reformatted proportionally spaced paragraphs in > realtime as one typed was quite a sight back then. Was this Interleaf or FrameMaker, or maybe the "ez" program from Carnegie Mellon University's Andrew project ? -- Ron Newman rnewman@thecia.net http://www2.thecia.net/users/rnewman/ ###### From: Tim Shoppa Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: Tue, 08 Feb 2000 10:42:04 -0400 Organization: Trailing Edge Technology Lines: 20 Message-ID: <389FF2FC.1C56DBAD@trailing-edge.com> References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> NNTP-Posting-Host: timaxp.trailing-edge.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ffx2nh5.news.uu.net 950024525 21712 63.73.218.130 (8 Feb 2000 15:42:05 GMT) X-Complaints-To: news@ffx2nh5.news.uu.net NNTP-Posting-Date: 8 Feb 2000 15:42:05 GMT X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!esel!cosy.sbg.ac.at!nntprelay.berkeley.edu!news-hog.berkeley.edu!feeder.via.net!newspump.monmouth.com!newspeer.monmouth.com!newsfeed.icl.net!news-hub.cableinet.net!Quza.UK.peer!uunet!ams.uu.net!ffx.uu.net!ffx2nh5!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49448 Ron Newman wrote: > The original RT PC had one *very* nasty misfeature, which repeatedly > burned people who were trying to port software from either DEC VAXen > or Intel PCs: > > Pointers to 4-byte entities had to be aligned on 4-byte boundaries. > BUT if you violated this rule, the RT PC would not crash your program > with a bus error or segmentation violation. Instead, the RT PC would > silently ignore the bottom 2 bits of your 32-bit pointer, rounding it > down to a 4-byte boundary! I think this "misfeature" falls in the nasal-demon category. If you do stuff with pointers that the C language spec says you aren't supposed to do, all bets are off. It would be nice if an error or warning was issued, but there's lots of other ways you can shoot yourself in the foot with C where no immediate error and obvious error message is issued. Tim. ###### From: bjh21@cus.cam.ac.uk (Ben Harris) Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: 8 Feb 2000 15:46:24 GMT Organization: University of Cambridge, England Lines: 21 Message-ID: <87pdog$4in$1@pegasus.csx.cam.ac.uk> References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> NNTP-Posting-Host: ursa.cus.cam.ac.uk Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!newsfeed.Austria.EU.net!nmaster.kpnqwest.net!npeer.kpnqwest.net!newsfeeds.belnet.be!news.belnet.be!colt.net!diablo.theplanet.net!news.vas-net.net!server2.netnews.ja.net!pegasus.csx.cam.ac.uk!bjh21 Xref: chonsp.franklin.ch alt.folklore.computers:49470 In article , Ron Newman wrote: >The original RT PC had one *very* nasty misfeature, which repeatedly >burned people who were trying to port software from either DEC VAXen >or Intel PCs: > >Pointers to 4-byte entities had to be aligned on 4-byte boundaries. >BUT if you violated this rule, the RT PC would not crash your program >with a bus error or segmentation violation. Instead, the RT PC would >silently ignore the bottom 2 bits of your 32-bit pointer, rounding it >down to a 4-byte boundary! Hardly the only system like this. The ARM 2 (when used with the MEMC) would load from the rounded-down word, but use the bottom two bits to decide how far to rotate the loaded quantity. This meant you could load sixteen-bit quantities at sixteen-bit alignments without too much pain. -- Ben Harris Unix Support, University of Cambridge Computing Service. If I wanted to speak for the University, I'd be in ucam.comp-serv.announce. ###### From: Tim Shoppa Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: Tue, 08 Feb 2000 11:56:53 -0400 Organization: Trailing Edge Technology Lines: 32 Message-ID: <38A00485.511C4273@trailing-edge.com> References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> NNTP-Posting-Host: timaxp.trailing-edge.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ffx2nh5.news.uu.net 950029014 617 63.73.218.130 (8 Feb 2000 16:56:54 GMT) X-Complaints-To: news@ffx2nh5.news.uu.net NNTP-Posting-Date: 8 Feb 2000 16:56:54 GMT X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!newsfeed.nyc.globix.net!uunet!nyc.uu.net!ffx.uu.net!ffx2nh5!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49425 Scott Wheeler wrote: > > On Tue, 08 Feb 2000 10:42:04 -0400, Tim Shoppa > wrote: > > >> Pointers to 4-byte entities had to be aligned on 4-byte boundaries. > >> BUT if you violated this rule, the RT PC would not crash your program > >> with a bus error or segmentation violation. Instead, the RT PC would > >> silently ignore the bottom 2 bits of your 32-bit pointer, rounding it > >> down to a 4-byte boundary! > > > >I think this "misfeature" falls in the nasal-demon category. If > >you do stuff with pointers that the C language spec says you aren't > >supposed to do, all bets are off. > > Which bit of the C language spec are you thinking of? It seems to me that the most obvious way to get misaligned pointers is to stick the pointer into an integer, do some manipulation on the integer, and then stick it back into a pointer. You have a point in that the C language spec doesn't prohibit you from doing this, but it also makes it clear that there's no guarantee about what will happen ("nasal demons") if you do this. Yes, there is an awful lot of code out there that casts pointers to ints and back again. Fortunately in many circles this practice is being increasingly frowned on. On the CPU's I've been working with most commonly over the past decade, in fact, sizeof(int) != sizeof(pointer). Tim. ###### From: Scott Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: Tue, 08 Feb 2000 16:46:14 +0000 Message-ID: References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> NNTP-Posting-Host: bmtech.demon.co.uk X-NNTP-Posting-Host: bmtech.demon.co.uk:158.152.102.124 X-Trace: news.demon.co.uk 950028243 nnrp-01:2943 NO-IDENT bmtech.demon.co.uk:158.152.102.124 X-Complaints-To: abuse@demon.net X-Newsreader: Forte Agent 1.6/32.525 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 18 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!news-feed.inet.tele.dk!bofh.vszbr.cz!newsfeed.tli.de!newsfeed.nacamar.de!newsfeed.icl.net!newspeer.clara.net!news.clara.net!skynet.be!dispose.news.demon.net!demon!news.demon.co.uk!demon!bmtech.demon.co.uk!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49483 On Tue, 08 Feb 2000 10:42:04 -0400, Tim Shoppa wrote: >> Pointers to 4-byte entities had to be aligned on 4-byte boundaries. >> BUT if you violated this rule, the RT PC would not crash your program >> with a bus error or segmentation violation. Instead, the RT PC would >> silently ignore the bottom 2 bits of your 32-bit pointer, rounding it >> down to a 4-byte boundary! > >I think this "misfeature" falls in the nasal-demon category. If >you do stuff with pointers that the C language spec says you aren't >supposed to do, all bets are off. Which bit of the C language spec are you thinking of? Scott -- (please de-mung address if replying by email) ###### From: rnewman@thecia.net (Ron Newman) Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: Tue, 08 Feb 2000 11:47:16 -0500 Organization: http://extra.newsguy.com Lines: 38 Message-ID: References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> NNTP-Posting-Host: p-338.newsdawg.com X-Newsreader: MT-NewsWatcher 2.4.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.berkeley.edu!pln-w!spln!extra.newsguy.com!newsp.newsguy.com!rnewman Xref: chonsp.franklin.ch alt.folklore.computers:49487 In article <389FF2FC.1C56DBAD@trailing-edge.com>, Tim Shoppa wrote: > Ron Newman wrote: > > The original RT PC had one *very* nasty misfeature, which repeatedly > > burned people who were trying to port software from either DEC VAXen > > or Intel PCs: > > > > Pointers to 4-byte entities had to be aligned on 4-byte boundaries. > > BUT if you violated this rule, the RT PC would not crash your program > > with a bus error or segmentation violation. Instead, the RT PC would > > silently ignore the bottom 2 bits of your 32-bit pointer, rounding it > > down to a 4-byte boundary! > > I think this "misfeature" falls in the nasal-demon category. If > you do stuff with pointers that the C language spec says you aren't > supposed to do, all bets are off. The C language spec, to my knowledge, requires no alignment restrictions. These are hardware-dependent. On the IBM PCs of the time, the C compiler enforced no alignment restrictions and added no padding space between structure fields, regardless of their size. VAX C compilers *did* add padding spaces to force alignment of structure fields, but the underlying hardware did not enforce such restrictions, so you could still do pointer arithmetic and packing to your heart's content. So if you were coming from either of these environments, the RT PC was an unpleasant surprise. Other machines that had alignment restrictions would helpfully issue segment faults or bus errors if you violated the restrictions, which made it much easier to find and fix the errors. -- Ron Newman rnewman@thecia.net http://www2.thecia.net/users/rnewman/ ###### Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> X-Newsreader: trn 4.0-test72 (19 April 1999) From: tl@arela.funcom.com (Torbjorn Lindgren) Lines: 22 Message-ID: X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly X-Complaints-To: admin@usenetserver.com NNTP-Posting-Date: Tue, 08 Feb 2000 12:05:42 EST Organization: UseNet Server, Inc. http://www.usenetserver.com - Home of the fastest NNTP servers on the Net. Date: Tue, 08 Feb 2000 17:05:42 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone1.usenetserver.com!cyclone1.usenetserver.com!news4.usenetserver.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49498 Ron Newman wrote: >In article <87p3h0$m2f$1@bcarh8ab.ca.nortel.com>, mwandel@nortel.ca >(Markus Wandel) wrote: > >> Then there was the IBM PC/RT which was some sort of RISC machine. > >Actually, the correct name was "RT PC". It was not a great success, >and was re-engineered and re-introduced as the RS/6000. It ran >a strange flavor of Unix called "AIX". It ran AIX 2, AOS (Academic Operating System, a BSD 4.3 derivate), and BSD 4.3/Reno (NOT the same as AOS). See the RT AOS FAQ [1] for more details, question A.16. All RT's *I* have seen were running what I was told was BSD 4.3/Reno, it was supposed to be some AOS RT's elsewhere though. I doubt the University in question had a single AIX RT though... (Yes, they had AT&T source licenses, and were running lots of different BSD version of different hardware). 1. http://www.uni-giessen.de/faq/archiv/ibm-rt-faq.aos/msg00000.html ###### Sender: lynn@LYNNPC Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> Reply-To: Anne & Lynn Wheeler From: Anne & Lynn Wheeler Message-ID: Organization: Wheeler&Wheeler Lines: 33 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Feb 2000 17:57:57 GMT NNTP-Posting-Host: 209.63.28.138 X-Complaints-To: support@adcomsys.net X-Trace: news-west.eli.net 950032677 209.63.28.138 (Tue, 08 Feb 2000 10:57:57 MST) NNTP-Posting-Date: Tue, 08 Feb 2000 10:57:57 MST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!howland.erols.net!newsfeed.cwix.com!cyclone-west.rr.com!news.rr.com|news-west.rr.com!easynews!news-west.eli.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49479 note also that PC/RTs were the NSFNET1 backbone routers. A PC/RT had 440kbit/sec adapter cards ... three RT/440kbit streams were channeled into an IDNX (basically a private phone switch) T1. Each NSFNET1 backbone site had racks & racks of PC/RTs handling 440kbit/sec streams connected to IDNX box running T1 connections between backbone sites. PC/RT ran a virtual machine supervisor (written in pl.8 & somewhat adopted from display writer follow-on project) under which ran a highly modified version of AT&T system 5.2. One of the porting problems to AIX on PC/RT was device drivers since they weren't actually interfacing to the bare hardware. AOS started out as project to port BSD to 370 mainframe and then was retargeted to PC/RT. misc. romp, pc/rt & aos references: http://www.garlic.com/~lynn/98.html#25 http://www.garlic.com/~lynn/98.html#26 http://www.garlic.com/~lynn/98.html#27 http://www.garlic.com/~lynn/99.html#2 http://www.garlic.com/~lynn/99.html#36 http://www.garlic.com/~lynn/99.html#64 http://www.garlic.com/~lynn/99.html#65 http://www.garlic.com/~lynn/99.html#129 http://www.garlic.com/~lynn/99.html#146 -- Anne & Lynn Wheeler | lynn@adcomsys.net, lynn@garlic.com http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/ ###### Path: chonsp.franklin.ch!not-for-mail From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: 08 Feb 2000 21:43:37 +0100 Organization: My own Private Self Lines: 62 Message-ID: <6un1pb1l3a.fsf@chonsp.franklin.ch> References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> NNTP-Posting-Host: chonsp.franklin.ch X-Trace: chonsp.franklin.ch 950042617 848 10.0.3.2 (8 Feb 2000 20:43:37 GMT) X-Complaints-To: news@chonsp.franklin.ch NNTP-Posting-Date: 8 Feb 2000 20:43:37 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: chonsp.franklin.ch alt.folklore.computers:49510 rnewman@thecia.net (Ron Newman) writes: > In article <389FF2FC.1C56DBAD@trailing-edge.com>, Tim Shoppa > wrote: > > > Ron Newman wrote: > > > > > > Pointers to 4-byte entities had to be aligned on 4-byte boundaries. > > > BUT if you violated this rule, the RT PC would not crash your program > > > > I think this "misfeature" falls in the nasal-demon category. If > > On the IBM PCs of the time, the C compiler enforced no alignment > > VAX C compilers *did* add padding spaces to force alignment of > > So if you were coming from either of these environments, the RT PC > was an unpleasant surprise. Also known as "all the worlds a vax" syndrome. Common among C programmers. > Other machines that had alignment restrictions > would helpfully issue segment faults or bus errors if you violated > the restrictions, which made it much easier to find and fix the errors. You obviously never met a Transputer. They actually use byte addressing pointers when reading char data type and word addressing pointers when addressing int type, like this: memory address as int* char* ------------- | | | | | 0 3-0 |-----------| | | | | | 1 7-4 |-----------| | | | |AA| 2 11-8 To read AA by somemething like this: int *a = 2; char b; b = * (char*)a; it would need an "shift left by 2 bits (2->8)" to do the typecast. So the oposite cast char* to int* dropped 2 bits (completely legal for an shift right), and then for the dereference all values for the resulting int* are valid values, so no trapping could even be possible! And yes, they did have a good reason for doing this: the instruction set used many base+offset type memory references and put and speed penalty on long constants, so one got here 2 bits for offsets for free. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Nerd, Geek, Unix Wizzard, Hacker, Sysadmin, Roleplayer, Mystic Computer: toy speeds work, you have more time to play with it ###### From: jones@cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: 8 Feb 2000 19:05:37 GMT Organization: The University of Iowa Lines: 11 Message-ID: <87ppe1$mjk$1@flood.weeg.uiowa.edu> References: NNTP-Posting-Host: pyrite.cs.uiowa.edu X-Trace: flood.weeg.uiowa.edu 950036737 23156 128.255.28.3 (8 Feb 2000 19:05:37 GMT) X-Complaints-To: usenet@news.uiowa.edu NNTP-Posting-Date: 8 Feb 2000 19:05:37 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!news-feed.inet.tele.dk!bofh.vszbr.cz!newsgate.cistron.nl!newsfeeds.belnet.be!news.belnet.be!skynet.be!feed2.newsfeeds.com!newsfeeds.com!marge.eaglequest.com!ord-feed.news.verio.net!news.uiowa.edu!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49516 From article , by tl@arela.funcom.com (Torbjorn Lindgren): > > All RT's *I* have seen were running what I was told was BSD 4.3/Reno, > it was supposed to be some AOS RT's elsewhere though. The RT I'm typing this on runs AOS (renamed ACIS to avoid name conflicts). It is a port of BSD 4.3, and the startup message still says BSD 4.3. Doug Jones jones@cs.uiowa.edu ###### Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) References: <87o5lj09gq@enews4.newsguy.com> <389FF2FC.1C56DBAD@trailing-edge.com> Organization: Daedalus Consulting From: don@news.daedalus.co.nz (Don Stokes) Message-ID: <950037978.922693@shelley.paradise.net.nz> Cache-Post-Path: shelley.paradise.net.nz!unknown@203-96-144-16.cable.paradise.net.nz X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Lines: 21 Date: Tue, 08 Feb 2000 19:20:54 GMT NNTP-Posting-Host: 203.96.152.26 X-Complaints-To: newsadmin@xtra.co.nz X-Trace: news.xtra.co.nz 950037654 203.96.152.26 (Wed, 09 Feb 2000 08:20:54 NZDT) NNTP-Posting-Date: Wed, 09 Feb 2000 08:20:54 NZDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!news-feed.inet.tele.dk!bofh.vszbr.cz!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!enews.sgi.com!news.xtra.co.nz!don Xref: chonsp.franklin.ch alt.folklore.computers:49517 Ron Newman wrote: >VAX C compilers *did* add padding spaces to force alignment of >structure fields, but the underlying hardware did not enforce >such restrictions, so you could still do pointer arithmetic and >packing to your heart's content. And to add to the confusion the VMS VAX C compiler *didn't* do alignment. It basically took the attitude that the architecture was byte-aligned, so you could put a word or longword anywhere you liked. Which caused grief when using gcc, which does alignment. Eg, from gcc/VMS's stat.h: typedef struct stat { ... unsigned st_uid; unsigned short st_gid; /* <---- The big screw... VAX-11 "C" doesn't do alignment so everything following this is wrong! */ dev_t st_rdev; off_t st_size; -- don ###### From: Ron Newman Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: 8 Feb 2000 13:02:36 -0800 Organization: Extra Newsguy News Service [http://extra.newsguy.com] Lines: 48 Message-ID: <87q09c$2248@edrn.newsguy.com> References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> <38A00485.511C4273@trailing-edge.com> NNTP-Posting-Host: p-105.newsdawg.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newspeer.te.net!news.indigo.ie!diablo.theplanet.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!nntp.abs.net!pln-e!spln!extra.newsguy.com!newsp.newsguy.com!edrn Xref: chonsp.franklin.ch alt.folklore.computers:49514 On Tue, 08 Feb 2000 11:56:53 -0400, in article <38A00485.511C4273@trailing-edge.com>, Tim stated... >> >> Pointers to 4-byte entities had to be aligned on 4-byte boundaries. >> >> BUT if you violated this rule, the RT PC would not crash your program >> >> with a bus error or segmentation violation. Instead, the RT PC would >> >> silently ignore the bottom 2 bits of your 32-bit pointer, rounding it >> >> down to a 4-byte boundary! >> > >> >I think this "misfeature" falls in the nasal-demon category. If >> >you do stuff with pointers that the C language spec says you aren't >> >supposed to do, all bets are off. >> >> Which bit of the C language spec are you thinking of? > >It seems to me that the most obvious way to get misaligned pointers >is to stick the pointer into an integer, do some manipulation on >the integer, and then stick it back into a pointer. I encountered this problem twice in my programming life -- first as a programmer on the X Window System project at MIT Project Athena, and again at Lotus Development Corporation. In both cases, I was porting code to the RT PC that had been developed on a different platform without alignment restrictions (X Window System on a VAX running Unix; Lotus 1-2-3 on an IBM PC running MS-DOS). In neither case was the code casting pointers to integers, or vice versa. Instead, the code was adding various small integers to a (char *) pointer, and then casting the (char *) to a (short *), (long *), (float *), or (double *). At MIT, the purpose of the code was to read and write X protocol to and from a socket. When we encountered this problem, we had to actually make an incompatible revision to the X protocol in order to include proper padding to satisfy the RT PC's alignment restrictions. This is why "X Version 9" was never publicly released -- we changed the version number to 10 halfway through its development after making the protocol revision. At Lotus, the code was reading and writing a file format that had already been defined for the PC, which also had no alignment restrictions. I don't remember how we finally fixed the problem -- we certainly did *not* change the file format! -- but it was messy. -- Ron Newman rnewman@thecia.net http://www2.thecia.net/users/rnewman/home.html ###### From: michael.wojcik@merant.com (Michael Wojcik) Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Date: 8 Feb 2000 22:31:28 GMT Organization: MERANT Inc. Lines: 100 Message-ID: <87q5g001k03@news2.newsguy.com> References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> <38A00485.511C4273@trailing-edge.com> <87q09c$2248@edrn.newsguy.com> Reply-To: michael.wojcik@merant.com NNTP-Posting-Host: p-542.newsdawg.com X-Newsreader: xrn 9.00 Originator: mww@lorelei-n Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!logbridge.uoregon.edu!pln-w!spln!extra.newsguy.com!newsp.newsguy.com!mww Xref: chonsp.franklin.ch alt.folklore.computers:49531 In article <87q09c$2248@edrn.newsguy.com>, Ron Newman writes: > On Tue, 08 Feb 2000 11:56:53 -0400, in article > <38A00485.511C4273@trailing-edge.com>, Tim stated... > > >> >> Pointers to 4-byte entities had to be aligned on 4-byte boundaries. > >> >> BUT if you violated this rule, the RT PC would not crash your program > >> >> with a bus error or segmentation violation. Instead, the RT PC would > >> >> silently ignore the bottom 2 bits of your 32-bit pointer, rounding it > >> >> down to a 4-byte boundary! > >> >I think this "misfeature" falls in the nasal-demon category. If > >> >you do stuff with pointers that the C language spec says you aren't > >> >supposed to do, all bets are off. > >> Which bit of the C language spec are you thinking of? C90 (ANSI/ISO 9899-1990), 6.3.4: A pointer to an object or incomplete type may be converted to a pointer to a different object type or different incomplete type. The resulting pointer might not be valid if it is improperly aligned for the type pointed to. I don't have C99 handy to check, but I'm guessing it has similar language. When Ron was working on X9 / X10 (see below), C90 hadn't been established yet, of course. But that restriction was not a surprise to most C practitioners, I think. Certainly it wasn't to me - K&R first edition discusses the alignment rules for struct and union, and makes it clear that alignment is up to the implementation, which should be a red flag against making assumptions about alignment portability. > In neither case was the code casting pointers to integers, or vice > versa. Instead, the code was adding various small integers to a > (char *) pointer, and then casting the (char *) to a (short *), > (long *), (float *), or (double *). Which is precisely the behavior that C90 warns against. I suspect this is as common as the problem Tim mentioned (manipulating pointer values as integers). > At MIT, the purpose of the code was to read and write X protocol > to and from a socket. When we encountered this problem, we had to > actually make an incompatible revision to the X protocol in order to > include proper padding to satisfy the RT PC's alignment restrictions. > This is why "X Version 9" was never publicly released -- we changed > the version number to 10 halfway through its development after making > the protocol revision. I assume that's when types like "CARD8" started appearing in the X structure definitions. When I was working on the RT, and we had to handle foreign data structures, we just didn't make any assumptions about local alignment restrictions. Do bytewise I/O and marshall / unmarshall the data into and out of the data structures. You already have to deal with endian issues, character set issues, etc. Not being able to read right into &my_struct isn't that much worse. I sympathize with your frustration. It's easy with hindsight to bash programmers who "packed" structures on architectures that allowed it, since even now many processors will perform better if they don't run into misaligned loads and stores, even though they handle them better than the ROMP did. (I'm not bashing the ROMP - that kind of logic would have been prohibitive in the ROMP design.) But memory was expensive then, and packing data made sense. FWIW: One of the last big RT projects I worked on was a test harness for PEX (the PHIGS - 3D graphics - X extension). Rather than write wrapper functions for all the PEX entry points, I tied the script parser to a set of C routines that built RT stack frames to match their interface descriptions and then called the functions indirect- ly. There were some fairly hairy nested structs and union in the PEX spec, and my code had to recursively parse them to figure out the alignment requirements and total size (with padding). It would have been quite a lot easier if there were no alignment requirements and the size was just the sum of the fields (modulo union overlaying). > At Lotus, the code was reading and writing a file format that had > already been defined for the PC, which also had no alignment restrictions. > I don't remember how we finally fixed the problem -- we certainly did > *not* change the file format! -- but it was messy. Probably what we did with misaligned data on strict-alignment machines - bytewise I/O into a buffer and pulled or pushed the appropriate bits field-by-field, letting the compiler handle alignment. -- Michael Wojcik michael.wojcik@merant.com AAI Development, MERANT (block capitals are a company mandate) Department of English, Miami University Q: What is the derivation and meaning of the name Erwin? A: It is English from the Anglo-Saxon and means Tariff Act of 1909. -- Columbus (Ohio) Citizen ###### From: plugh@NO.SPAM.PLEASE (Caveman) Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) Organization: Crystal Cave Lines: 26 Message-ID: <87qf4o$kco@adsl-216-61-138-75.dsl.hstntx.swbell.net> References: <87o5lj09gq@enews4.newsguy.com> <38A00485.511C4273@trailing-edge.com> <87q09c$2248@edrn.newsguy.com> <87q5g001k03@news2.newsguy.com> X-No-Archive: yes Date: 8 Feb 2000 19:16:08 -0600 NNTP-Posting-Host: 216.61.138.75 X-Complaints-To: abuse@swbell.net X-Trace: news.swbell.net 950059014 216.61.138.75 (Tue, 08 Feb 2000 19:16:54 CST) NNTP-Posting-Date: Tue, 08 Feb 2000 19:16:54 CST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newspeer.te.net!news.indigo.ie!news-out.cwix.com!newsfeed.cwix.com!newsfeed.berkeley.edu!cyclone.swbell.net!news.swbell.net.POSTED!news.swbell.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49523 In article <87q5g001k03@news2.newsguy.com>, Michael Wojcik wrote: >[...] >I sympathize with your frustration. It's easy with hindsight to bash >programmers who "packed" structures on architectures that allowed it, >[...] It's a so-called "paradigm shift." Computing was changing from a world where human labor was a trivial cost relative to hardware capacity and performance to one where the opposite is true. One might well argue that our ability to change our environment has vastly outstripped our wisdom to decide how individual humans might best adapt to and benefit from those changes. Our embracing of a statistical worldview challenges us to impose the individual human as the quantum of statistical granularity in our analyses. Otherwise we will increasingly approach a culture of universal servitude to the engines of our own ingenuity. -- "You are in a maze of twisty little passages, all different." ###### Sender: meissner@tiktok.cygnus.com Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> <38A00485.511C4273@trailing-edge.com> From: Michael Meissner Message-ID: Organization: Red Hat Inc. Lines: 105 X-Newsreader: Gnus v5.7/Emacs 20.4 Date: 08 Feb 2000 21:05:25 -0500 NNTP-Posting-Host: 209.192.197.34 X-Complaints-To: abuse@shore.net X-Trace: news.shore.net 950061926 209.192.197.34 (Tue, 08 Feb 2000 21:05:26 EST) NNTP-Posting-Date: Tue, 08 Feb 2000 21:05:26 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!newspump.monmouth.com!newspeer.monmouth.com!news.shore.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49542 Tim Shoppa writes: > Yes, there is an awful lot of code out there that casts pointers > to ints and back again. Fortunately in many circles this practice > is being increasingly frowned on. On the CPU's I've been working > with most commonly over the past decade, in fact, > sizeof(int) != sizeof(pointer). Another fun one is machines that have differnt types of pointer formats. For example, the Data General MV/Eclipse had 4 types of pointers at the hardware level (the MV/Eclipse was the 32-bit extension of the original Nova which did not have byte addressing at all and the byte instructions were retrofitted on to the architecture): 1) pointer to byte 2) pointer to 16-bit word 3) pointer to 16-bit word + bit offset to point to a single bit 4) bit offset to point to a single bit within the first 1/16 of memory in the current segment. The 16-bit word pointer format looked like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |@|segmt| offset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The @ is the indirect bit (if the the instruction doing the load or store had the indirect bit set, then the hardware would check the top bit of the address, and if set, it would use the remaining 31 bits as an address to load the next address, which in turn would be checked for the @ bit being set -- the machine would fault into the kernel if more than 16 levels of indirection were encountered). The byte pointer was the word pointer format shifted left one bit (losing the @ bit), and the bottom bit described which byte to reference: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |segmt| offset|B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ You could not do a 16 or 32 bit load via a byte pointer, you had to use a word pointer. Needless to say when I first wrote the C compiler for this beast, following K&R, I would see code like: int a, b; char *c; a = &b; c = a; Which given the conversion rules of just copying the bits, would not do the right thing. The above code was usually people's attempt at rewriting malloc, using the bottom bit as bit that said whether the block was free or not. Other fun things about the Data General MV/EClipse (to add to the worst ISA thread): 1) Only 4 integer registers and 4 floating point registers were available (there were stack registers for the current SP, frame pointer, and low bound, but you could not reference these directly -- you had to move them into an integer register with the call instruction setting up AC3 == frame pointer). 2) You could only use AC2 and AC3 as the base registers for word/fullword memory references. 3) The stack went in the oppisite direction of most machines people are familiar with these days. This was the days before prototypes and varargs, when men were men, and everybody wrote their varargs handling by hand. 4) IBM floating point format (mantissa was represented in hex, not binary), which meant you usually lost 2 bits of precision. No hidden bit, no infinities, no NaNs. 5) No sign extending forms of the load byte/load 16-bit word instructions. 6) Arithmetic shifts right were rather expensive (3 clocks). I don't recall whether the machine had a barrel shifter or not (I think it did -- but earlier Eclipses and Novas did shifts bit at a time). 7) Ring based architecture that used fixed segments for the rings. User programs started out in ring 7, the kernel in ring 0. This meant that the maximum virtual memory a program could use was 256 megabytes. 8) Standard call instructions needed to check for cross ring calls and copy the arguments to the stack in the inner ring (the offset was used to point into a call gate table). Similarly, the return instruction had to deal with unwinding the stack when returning to the outer ring. The ring architecture made emulation of signals very tricky. 9) The 0 opcode was not illegal, but rather a jump to location 0 in the current segment, which in user code usually had 0 in it. In the 16-bit kernel mode, location 0 had the address of the interrupt. 10) Variable sized instructions (1-4 16-bit words). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886 Work: meissner@redhat.com phone: 978-486-9304 fax: 978-692-4482 Non-work: meissner@spectacle-pond.org ###### Sender: meissner@tiktok.cygnus.com Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) References: <87o5lj09gq@enews4.newsguy.com> <87p3h0$m2f$1@bcarh8ab.ca.nortel.com> <389FF2FC.1C56DBAD@trailing-edge.com> From: Michael Meissner Message-ID: Organization: Red Hat Inc. Lines: 18 X-Newsreader: Gnus v5.7/Emacs 20.4 Date: 08 Feb 2000 21:11:26 -0500 NNTP-Posting-Host: 209.192.197.34 X-Complaints-To: abuse@shore.net X-Trace: news.shore.net 950062286 209.192.197.34 (Tue, 08 Feb 2000 21:11:26 EST) NNTP-Posting-Date: Tue, 08 Feb 2000 21:11:26 EST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!skynet.be!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.shore.net!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49545 rnewman@thecia.net (Ron Newman) writes: > The C language spec, to my knowledge, requires no alignment > restrictions. These are hardware-dependent. That's not quite correct. The ISO C standard requires that address of the first element (all elements of a union) of an aggregate object be the same as the address of the object itself when cast to a suitable common pointer. That all members of an array or structure are monotonically increasing. And that two structures which have the same initial elements, it is guaranteed that those elements are located at the same offset from the beginning of the structure. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886 Work: meissner@redhat.com phone: 978-486-9304 fax: 978-692-4482 Non-work: meissner@spectacle-pond.org ###### Newsgroups: alt.folklore.computers Subject: Re: IBM RT PC (was Re: What does AT stand for ?) References: <87ppe1$mjk$1@flood.weeg.uiowa.edu> X-Newsreader: trn 4.0-test72 (19 April 1999) From: tl@arela.funcom.com (Torbjorn Lindgren) Lines: 43 Message-ID: X-Abuse-Info: Please be sure to forward a copy of ALL headers X-Abuse-Info: Otherwise we will be unable to process your complaint properly X-Complaints-To: admin@usenetserver.com NNTP-Posting-Date: Wed, 09 Feb 2000 10:03:48 EST Organization: UseNet Server, Inc. http://www.usenetserver.com - Home of the fastest NNTP servers on the Net. Date: Wed, 09 Feb 2000 15:03:48 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!newshunter!cosy.sbg.ac.at!newsfeed.Austria.EU.net!nmaster.kpnqwest.net!npeer.kpnqwest.net!EU.net!news-peer.gip.net!news.gsl.net!gip.net!news.maxwell.syr.edu!cyclone1.usenetserver.com!cyclone1.usenetserver.com!news4.usenetserver.com.POSTED!not-for-mail Xref: chonsp.franklin.ch alt.folklore.computers:49549 Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >From article , >by tl@arela.funcom.com (Torbjorn Lindgren): >> >> All RT's *I* have seen were running what I was told was BSD 4.3/Reno, >> it was supposed to be some AOS RT's elsewhere though. > >The RT I'm typing this on runs AOS (renamed ACIS to avoid name conflicts). >It is a port of BSD 4.3, and the startup message still says BSD 4.3. If you had read the whole posting you would have noticed that I gave references to backup up the claim that there WERE a BSD 4.3/Reno port that was distinct from AOS, albeit using certain files from the AOS distribution due to the fact that not all information on the hardware was available. It's easy to find news postings (using Deja) mentioning similar things done using BSD 4.4 and which seems to suggest that it had been done with 4.3 before that. Some of the postings says that there were three distinct BSD ports done, 4.3, 4.4L-build-16 and 4.4L-build-501. Unless I'm misremembering badly the involved parties should have know what they were talking about, IIRC they had both AOS and BSD 4.3/Reno machines running in other physical locations... As I said earlier it was on a University, and they had both an AT&T source code license and AOS & BSD distributions, which supposedly were the hard-to-get parts (both the 4.3 and 4.4 ports seems to have required "BSD encumbered", which implies AT&T source code license) Here's three discussion relevant discussion I found on the first try [1] [2] [3]. Message [4] is part of the last discussion, and are one where 4.3reno and AOS seems to be regarded as distinct entities by people who should know. 1. http://www.deja.com/=dnc/getdoc.xp?AN=412425359 2. http://www.deja.com/=dnc/getdoc.xp?AN=135265103 3. http://www.deja.com/=dnc/getdoc.xp?AN=101092451 4. http://www.deja.com/=dnc/getdoc.xp?AN=101266536