Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pacbell.com!pacbell!rtech!mtxinu!taniwha!paul From: paul@taniwha.UUCP (Paul Campbell) Newsgroups: comp.arch Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: <807@taniwha.UUCP> Date: 6 Apr 91 02:07:23 GMT References: <4919@lib.tmc.edu> <5277@ns-mx.uiowa.edu> Reply-To: paul@taniwha.UUCP (Paul Campbell) Organization: Taniwha Systems Design, Oakland Lines: 66 In article <5277@ns-mx.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >In article <23615@as0c.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >>In article <1991Apr04.023845.3501@kithrup.COM> >>sef@kithrup.COM (Sean Eric Fagan) writes: >> >>>I defy you to come up with a PROPERLY WRITTEN program that will break. >> >>My pleasure, sir. >> DIMENSION BIGMAT(50000,50000) >> DOUBLE PRECISION BIGMAT > >People forget history so quickly these days! The Burroughs 5000 and >descendants all used segmented architectures, and they routinely handled >two dimensional arrays as an array of pointers to segments. That is >precisely how Burroughs FORTRAN would have handled the above case, and >if 50000 double's was too big for one segment, it would have automatically >made the array into a 3 or 4 dimensional array, completely hiding the I worked for a computing center for a university that had a 6700 for many years. Back in those days there weren't many languages you could por6yt code around in (for the 6700 we had fortran, cobol, pl/1 and to a lesser extent pascal) of these most of the code people tried to port was in fortran ... the biggest pain was fortran arrays FOR EXACTLY THIS REASON - people write in fortran and pass slices of arrays around all the time, if your fortran arrays aren't stored in memory 'just so' then all sorts of code breaks. Every time someone brought in another matrix math package in that they couldn't get ported I alwys new exactly what was wrong. Something else that also often broke fortran programs on the 6700 was the stack - fortran back in those days didn't really have one - parameters were static (global), recursive calls really screwed this up because the 6700 fortran got too smart for its own good (or programmers did wierd stuff they could get away with on their 360 or whatever) For what it's worth cobol was much more portable :-( There was a bcpl port, it modeled memory simply as one giant array and pretended it was running on a different machine (the pascal heap was done the same way). Noone every ported c as far as I know - you would probably have to do things the same as for bcpl or leave it soley as a systems programming language. (Contrary to popular belief there was (is) an assembler for the machine - several of them in fact - but for obvious resons they weren't available for common usage). >I remember a statistic from Burroughs that the average segment on their >machines was less than 64 words long (48 bits per word). The code of >each procedure was in a different segment, each array was a different >segment, and so on. This was only if you really wanted to, often many functions would end up in the same segment (depends on the compiler) >I never heard a Burroughs programmer complain about segments the way 8086 >programmers do because the Burroughs architectures did it right! I've Well at least they did it better - big arrays were still a pain (plus the fact that indirect pointers and stacks (the equivalents to page tables in this environment) could not be paged/swapped this also limited how big arrays could actually get). Paul Campbell -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P "But don't we all deserve. More than a kinder and gentler fuck" - Two Nice Girls, "For the Inauguration"