From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!cs.utexas.edu!uunet!news.uiowa.edu!news Sun Jan 30 13:23:16 1994 Flags-MM: 000000000000 Article: 58978 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!cs.utexas.edu!uunet!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.folklore.computers Subject: Re: Block structure keywords Date: 28 Jan 1994 19:51:07 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 41 Distribution: inet Message-ID: <2ibqbb$hvv@nexus.uiowa.edu> References: <1994Jan28.143343.8650@spider.co.uk> NNTP-Posting-Host: pyrite.cs.uiowa.edu Status: R >From article <1994Jan28.143343.8650@spider.co.uk>, by jmorris@spider.co.uk (John Morris): > > For example "if ..... fi". Quite a few languages have or had that, but > Algol-68 also has "case .... esac" and, as I recall (mayhap wrongly) > "do .... od". Probably others too - it's been a while. > > What always niggled me was its use of "begin ... end" instead of > "begin ... nigeb".... The joke went farther. Algol 68 had block comments set off with the keywords comment and end, but it should have been comment and tnemmoc! Further, proper reflection on the symmetry of do and od makes it clear that the correct symmetric pairs are: do ob - if the closing keyword is on the same line. do - if the closing keyword is directly under the opening keyword. qo do - if the closing keyword is indented under the opening keyword. op - (this is a double reflection, or a rotation.) Other words can be similarly reflected on no on on -- the first two are poor approximations ou uo -- but the last is pretty good. There are serious questions of what the reflected keyword should be for blocks that end on the next page, and there are serious design problems for keywords that aren't constructed of reflectable letters in the roman alphabet. Escape to non-roman alphabets helps for some letters, but you'll have to design your own text font for some keywords. The above thoughts aren't original. There was a series of letters to Sigplan Notices about 15 years ago with titles like "do considered od" that drove the subject into the ground. Doug Jones jones@cs.uiowa.edu From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!world!dp Wed Mar 9 09:34:00 CST 1994 Article: 62340 of alt.folklore.computers Xref: uchinews comp.fonts:11851 comp.lang.c:63637 alt.folklore.computers:62340 Newsgroups: comp.fonts,comp.lang.c,alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!world!dp From: dp@world.std.com (Jeff DelPapa) Subject: Re: Help identify book on typesetting of computer programs Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <2lj0sb$pg0@hobbes.cc.uga.edu> Distribution: usa Date: Wed, 9 Mar 1994 05:39:12 GMT Lines: 49 Status: R In article <2lj0sb$pg0@hobbes.cc.uga.edu>, Michael Covington wrote: >Sometime in the last few years I saw a book about the layout and >typography of computer programs. The author proposed an elaborate >way of setting C programs so that the function name would be in >large type at the top, followed by a descriptive comment in smaller >type, and then the text of the function... > >I can't remember the author's name, nor the title, and a fair bit of >rummaging through our library's online catalog hasn't yielded anything. > Sorry, I can't help you with the book. I will just reflect sadly on a step backwards. The MIT descended LISPM's had this sort of thing as an editor mode, electric-font-lock -- It automatically switched between a number of user chosen typefaces as you typed your code in. It would put code in a normal, monospaced typeface, the name of the function in uppercase bold, your comments could be in a proportionally spaced typeface, etc. One of my more crazed coworkers had it put all global symbols in italics (required the defvars to have been evaluated or loaded, and it made typing spaces slow, so it wasn't generally adopted -- this was 1982, the machine was 0.3mips, it could be excused) The result was much more readable code, the body could remain monospaced, (so the indentation worked), but the comments could be in a much more readable face, and one that let you pack a few more words on the line. (it was even possible to do it in a way that the fonts could be chosen by the user -- so those that needed the "over 40" font, wouldn't annoy those that wanted stuff in flyspeck 5x5, so they could cram that much more on the screen) Not bad for a system developed in 1978 (contemporary with 11-780's, vt-100's, predating ethernet). Then we had to port to unix boxes, were font isn't a concept that the compiler understands -- we wound up passing an uglification ray over the code, stripping out all the font change codes so that the bitty boxes could cope (font switching was handled by embedded codes, which the lispm compilers ignored.). What made it particularly depressing was that all the comment lines became instantly too wide for the screen.... Machines are almost two orders of magnitude faster, everything comes with a high res screen, and we have abandonded somthing which helps us cope with complexity. I am pretty certain it will reappear eventually, (and likely with great fanfare) -- this is just ensuring that some "prior art" gets noted. From uchinews!cdsmail!jitze Fri Apr 15 13:39:41 CDT 1994 Article: 65161 of alt.folklore.computers Newsgroups: alt.folklore.computers Path: uchinews!cdsmail!jitze From: jitze@svl.cdc.com (Jitze Couperus) Subject: Re: Olde Englishe Currency Organization: Control Data Systems Date: Thu, 14 Apr 1994 18:02:10 GMT Message-ID: References: <2ogpmh$4tj@nuscc.nus.sg> <1994Apr13.193611.16869@midway.uchicago.edu> Sender: usenet@cdsmail.cdc.com (News Poster) Status: R enf1@ellis.uchicago.edu (Eric Fischer) writes: >Algol, though, I think had a specific datatype for pre-decimal >currency values, complete with overloaded operators for doing the >various mathematical operations you might want to do with it. (It >may not have been Algol, actually -- but something from around the >same era) Likewise, a very early Cobol compiler...ICL (then ICT) rebadged the RCA 301 as the ICT 1500 so we had to modify the compiler (it was only the second commercially available compiler for that language) to handle in fact 2 separate data types. This was because pennies were recorded on punched cards in 2 styles - either as 2 card columns capable of holding (as you might expect) the values 00 thru 11, or in a single column using the "zone" locations for 10d and 11d values. So depending on whether you were attempting to read (or punch) which of these recording styles, you declared the data type as DISPLAY-4 or DISPLAY-5 if memory serves correctly. I can't remember what DISPLAY-1,2,3 were used for. And indeed, the usual arithmetic verbs (ADD, SUBTRACT, MULTIPLY,...) were "overloaded" to correctly handle each flavor of data type. The code generated was tortuous because this was a BCD machine (no binary data type as we know it today) with no hardware multiply or divide, and even add/subtract were handled by table-lookup at the hardware level. So to add two sterling amounts you had to reduce both operands to pennies (multiply pounds by 240, shillings by 12, and add in the penny value) add the two and then do a series of modulo divides to get the result back into the pounds/shillings/pennies format. What a pain - but because the multiply and divide subroutines each produced distinctive tones on the operator's loudspeaker, programs with a lot of sterling manipulation produced very pleasant musical chords to soothe the operator (as opposed to the ugly snarling noises emitted by the compile process). -- Jitze Couperus | jitze@svl.cdc.com Control Data Systems Inc. | Voice (408) 496-4334 5101 Patrick Henry Drive, Santa Clara, CA 95054 | FAX (408) 496-4106 From hnsngr@sirius.com Fri Jun 16 08:52:21 CDT 1995 Article: 105225 of alt.folklore.computers Xref: uchinews alt.folklore.computers:105225 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news-e1a.megaweb.com!newstf01.news.aol.com!uunet!in1.uu.net!sun.sirius.com!slip147.sirius.com!user From: hnsngr@sirius.com (Ron Hunsinger) Newsgroups: alt.folklore.computers Subject: Re: Quality of earliest compilers (was: 64 bit Linux?) Date: Fri, 16 Jun 1995 02:38:57 -0700 Organization: ErsteSoft Lines: 61 Message-ID: References: <3rcrq6$rks@fg70.rz.uni-karlsruhe.de> <3r1ano$1dp@fu-berlin.de> <1995Jun10.131928.13094@rpp386> NNTP-Posting-Host: slip147.sirius.com Status: R Thomas Koenig (ig25@fg70.rz.uni-karlsruhe.de) writes: > I've always wondered how good the output of the very first FORTRAN > compiler, developed at IBM, really was. > > It was in direct competition to hand assembly; it can't have been bad, > or people wouldn't have used it... > > What sort of optimization techniques did it use? What kind of hardware > did it run on, for that matter? J. Backus, the author of the first Fortran compiler, once wrote that he would lie awake nights, sweating that there would be some imaginable optimization that an assembler programmer might come up with that his compiler would miss. It was a 17-pass compiler. Took forever to compile anything, but man oh man, did it produce good code. For its first test, they brought in an engineer who had never programmed before, and taught him the language in the morning. He wrote his first program that afternoon, and got a syntax error on the first compile. The second compile was clean, and the program produced the correct output. They then turned over the compiled object code to several assembler programmers, who were forced to admit that they could not find any way to improve it. Backus' sleepless nights had not been in vain. And it was essential that it should come out so well. If the compiler had merely produced good code, rather than excellent, nobody would have used it. There was too much prejudice against the notion of compilation. Many of the optimizations it did are still being forgotten and rediscovered every few compiler releases: common subexpression elimination, loop invariant removal, strength reduction, iteration variables, loop unwinding, and so forth. But it did many optimizations that have never or rarely been seen since. You could give the compiler frequency directives, telling it how often you expected each leg of a branch to be taken, and it would rearrange the code to minimize the average number of branch instructions executed. In complicated cases involving spaghetti code with lots of interlocking conditionals, the compiler would simulate a routine to gather statistics about how often each basic block would be likely to be executed, using the frequency directives if they were available or sample data if not, and figure out from that the best code sequence to use. The code: DIMENSION A(10,10),B(10) DO 10 I = 1,10 B(I) = 0.0 DO 10 J = 1,10 10 A(I,J) = 0.0 would optimize to a block move instruction to erase the block of memory containing A and B to zeros. -Ron Hunsinger From uchinews!linac!uwm.edu!spool.mu.edu!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!asuvax!ukma!morgan Tue Sep 21 12:32:11 CDT 1993 Article: 48843 of alt.folklore.computers Newsgroups: alt.folklore.computers Path: uchinews!linac!uwm.edu!spool.mu.edu!howland.reston.ans.net!math.ohio-state.edu!cs.utexas.edu!asuvax!ukma!morgan From: morgan@engr.uky.edu (Wes Morgan) Subject: Re: Incompetent students (was: Incompetant user stories...) Message-ID: Sender: news@ms.uky.edu (USENET News System) Nntp-Posting-Host: a.ecc.engr.uky.edu Organization: University of Kentucky College of Engineering, Lexington, KY USA References: <1993Sep2.073350.9679@cs.aukuni.ac.nz> <1993Sep7.120816.1488@foobar.hanse.de> <1993Sep8.234906.342@grendel.demon.co.uk> <1993Sep13.234129.902@bay.cc.kcl.ac.uk> Date: Tue, 21 Sep 1993 16:27:04 GMT Lines: 162 Status: R >jes@grendel.demon.co.uk (Jim Segrave) writes: > >> Secondly, each student is handed some other student's submission with >> a change specification. The original author and the modifier are both >> graded on the success of the modified program. No, no, no...*here's* how it should be done: [ Lights up on university classroom. STUDENTS are lounging in their ] [ seats, chatting and passing the time. STUDENTS A AND B are actu- ] [ ally reading over their notes; the other STUDENTS ignore them com- ] [ pletely. PROFESSOR enters the room, with three ASSISTANTS carrying ] [ stacks of rectangular boxes. The STUDENTS fall silent as the PRO- ] [ FESSOR approaches the podium: ] PROFESSOR: Good morning. Today, we will be discussing code maintenance. [ STUDENTS groan, moan ad lib. ] STUDENT A: Isn't that what we've been doing all semester, sir? ASSISTANT 1: Right, kid, right... PROFESSOR: In a limited fashion, you are correct; however, we will be per- forming this task in a "real world" environment. STUDENT B: About time we did something real... PROFESSOR: I was recently cleaning out some old lab space, and I found these. [ PROFESSOR opens box ] [ SFX: dramatic "dum do DUMMMM!" from low brass instruments ] STUDENT A: Why, those are... STUDENT B: I've seen those before... STUDENT C: Yeah, those are note cards; my dad used those before Post-Its came out. PROFESSOR: Tsk...so young... No, class, these are punch cards. Also known as Hollerith cards, these were once the only means by which user programs could be loaded into the computer. Please, each of you take a box. [ ASSISTANTS laughingly distribute boxes to STUDENTS, who blow the dust ] [ away and open them. ] STUDENT A: Hey, what's "//MYPROG JOB"? STUDENT B: "//GO.SYSIN DD *"? STUDENT D: Great, I was going to go buy some Post-Its, but now... PROFESSOR: No, no, they aren't scrap paper...Look at them! STUDENT C: Hey, mine have FORTRAN on them! PROFESSOR: FORTRAN IV, to be precise... STUDENT F: Hey, what's ASMG? PROFESSOR: Oh, you're going to *enjoy* that one... STUDENT B: "ADD ONE TO X.".....looks kind of like BASIC, but dumber. PROFESSOR: Each of you has a code project from the early 1960s. In our scenario, our company has acquired the assets of an undervalued competitor; you have been tasked with bringing their computing "up to date." Unfortu- nately, the only source code available are these cards. Your task, therefore, is... STUDENT A: I don't like where this is going... STUDENT G: Hey, look, a snowstorm! PROFESSOR: to ascertain the function of these programs, recode them in your choice of FORTRAN 90, C, C++ or Ada, and use the original data cards for veri- fication of your work. STUDENT A: How are we supposed to figure this out from *cards*! Where's the docu- mentation? PROFESSOR: Ah, unfortunately, no one ever wrote documentation for these programs; you'll have to trace through them yourselves. STUDENT F: But we never learned this ASMG, whatever it is... PROFESSOR: Are *you* going tell your boss that? STUDENT G: Um...is the order of the cards important? PROFESSOR: Oh, my, yes -- most folks didn't put sequence numbers on their cards. STUDENT G: I need a drink... PROFESSOR: This will, of course, be due by Monday morning. I've found a card reader, but it's at another site... STUDENT A: Oh, over in Main Computing? PROFESSOR: No, actually it's at Weeble State; they're the only ones I could find who still had a card reader. STUDENT B: But that's a 2-hour drive! PROFESSOR: Remember, we're in the corporate world now! You have to get it done; do you think the boss cares about a 2-hour drive? Good luck, and I'll expect your programs Monday. You'll find the manuals for these 1960s programming languages in the Computer Science "Abandon All Hope" Collec- tion of the main library. [ STUDENTS sit numbly, rifling through their boxes and muttering... ] PROFESSOR: By the way, someone call 911; STUDENT G has apparently died of paper cuts...occupational hazard back then, you know... -- Wes Morgan ----- University of Kentucky ----- morgan@engr.uky.edu Mailing list for AT&T StarServer E/S admins - starserver-request@engr.uky.edu GCS/E/MU d--- -p+ c++ l+ m* s++/++ !g w+ t+ r gharshana-neti -- mental floss? From Charlie_Gibbs@mindlink.bc.ca Fri Dec 29 13:05:25 CST 1995 Article: 127062 of alt.folklore.computers Xref: uchinews alt.folklore.computers:127062 Path: uchinews!vixen.cso.uiuc.edu!newsfeed.internetmci.com!newsxfer2.itd.umich.edu!agate!news.mindlink.net!mindlink.bc.ca!a218 From: Charlie_Gibbs@mindlink.bc.ca (Charlie Gibbs) Newsgroups: alt.folklore.computers Subject: Re: Hopper and COBOL (Was: Where did "bug" come from) Date: Tue, 26 Dec 95 17:46:22 -0800 Organization: MIND LINK! - British Columbia, Canada Lines: 190 Distribution: world Message-ID: <81813-820028782@mindlink.bc.ca> NNTP-Posting-Host: mindlink.net Status: R [This isn't in the proper place in the thread, but the original message expired at our site while I was off making merry (as opposed to making Mary ;-)...] In article afcasta@texas.net (Al Castanoli) writes: >In article , aa318@FreeNet.Carleton.CA >(John Coughlin) wrote: > >| Heinz W. Wiggeshoff (ab528@FreeNet.Carleton.CA) writes: >| > Chris (cfriend@innotts.co.uk) writes: >| >> In article <4astph$c4@sundog.tiac.net>, sailboat@tiac.net (Robert >| >> Schuldenfrei) says: >| >>> >| >>> I once saw >| >>>MOVE GOLDILOCKS TO HOUSE-OF-THE-THREE-BEARS. In fact the whole >| >>>fairy tale was written in legal COBOL - >| >>> >| >> Oh no! I always wanted to write a play in COBOL, but it looks like >+ >> that's not an original idea! >| > >| > It might be a Greek tragedy! >| >| More likely a geek tragedy. > >If Charlie Gibbs is reading, maybe he'd be interested in posting it >again here as he did on May 18th of this year... I was wondering when this would come up. OK, here it is again, back by popular demand. Please excuse the upper case - that's the way we did things back in those days... Charlie_Gibbs@mindlink.bc.ca If your nose runs and your feet smell, you're built umop-apisdn. THE COMMON BUSINESS-ORIENTED GOLDILOCKS (which originally appeared in an ancient issue of Datamation): 000001 IDENTIFICATION DIVISION. 000002 PROGRAM-ID. ACOBOLFABLE. 000003 DATE-WRITTEN. ONCE UPON A TIME. 000004* THIS IS AN EXAMPLE OF COBOLX VERSATILITY. 000005 000006 000007 000008 ENVIRONMENT DIVISION. 000009 CONFIGURATION SECTION. 000010 OBJECT-COMPUTER. ANY MUSIC-BOX, MEMORY SIZE 8**64 CHARACTERS 000011 19 TAPE-DRIVES, 11 DISC-DRIVES, 000012 1 GOLDILOCKS, 3 BEARS. 000013 INPUT-OUTPUT SECTION. 000014 FILE-CONTROL. 000015 SELECT TAPE-DRIVES, ASSIGN TO CREDITOR. 000016 SELECT DISC-DRIVES. 000017 SELECT GOLDILOCKS, SELECT BEARS; ASSIGN TO ONE-COTTAGE. 000018 I-O-CONTROL. 000019 APPLY RED-TAPE ON TAPE-DRIVES 000020 APPLY HOFFNUNG-RECORD ON DISC-DRIVE 000021 APPLY GOLDI, BEARS ON COTTAGE. 000022 000023 000024 000025 DATA DIVISION. 000026 FILE SECTION. 000027 FD GOLDI 000028 LABEL RECORDS ARE STANDARD 000029 VALUE OF FILE-ID IS 'GOLDILOCKS' 000030 DATA RECORD IS GOLDILOCKS. 000031 01 GOLDILOCKS. 000032 02 HGT SIZE IS 62 INS. 000033 02 WGT SIZE IS 110 LBS. 000034 02 VITAL-STATS. 000035 03 B 38. 000036 03 W 24. 000037 03 H 36. 000038 02 RATING 100%. 000039 01 FD 3-BEARS 000040 LABEL RECORDS ARE STANDARD 000041 VALUE OF FILE-ID IS 'BEARS' 000042 DATA RECORDS ARE DADDY-BEAR, MUMMY-BEAR, BABY-BEAR. 000043 01 DADDY-BEAR. 000044 02 HGT 70 INS. 000045 02 WGT 750 LBS. 000046 02 COLOR OF EYES BLOODSHOT. 000047 02 DISPOSITION UNBEARABLE. 000048 01 MUMMY-BEAR. 000049 02 HGT 65 INS. 000050 02 WGT 700 LBS. 000051 02 COLOR OR EYES BLUE. 000052 02 DISPOSITION BEARABLE. 000053 01 BABY-BEAR. 000054 02 HGT 40 INS. 000055 02 WGT 200 LBS. 000056 02 COLOR OF EYES BLUE. 000057 02 DISPOSITION INFANTILE. 000058 000059 WORKING-STORAGE SECTION. 000060 01 COTTAGE PICTURE IS COZY. 000061 02 KITCHEN. 000062 03 TABLE SIZE IS LARGE, VALUE IS 1. 000063 03 CHAIRS SIZE IS MEDIUM, VALUE IS 3. 000064 02 PORRIDGE. 000065 03 KING-SIZE OCCURS 1 TIMES. 000066 03 QUEEN-SIZE OCCURS 1 TIMES. 000067 03 PRINCE-SIZE OCCURS 1 TIMES. 000068 02 DOOR SIZE IS USUAL, VALUE IS OPEN. 000069 02 BEDROOM. 000070 03 BED. 000071 04 LARGE OCCURS 1 TIMES. 000072 04 MEDIUM OCCURS 1 TIMES. 000073 04 SMALL OCCURS 1 TIMES. 000074 03 WINDOW SIZE IS SMALL, VALUE IS OPEN. 000075 01 RIGHT-COTTAGE REDEFINES COTTAGE, VALUE IS SAME. 000076 01 KING-SIZE-BED-SLEPT-IN SIZE IS BIG, VALUE IS ROCK-BOTTOM. 000077 01 QUEEN-SIZE-BED-SLEPT-IN SIZE IS MEDIUM, VALUE IS DEPRESSED. 000078 01 NO-PORRIDGE SIZE IS SMALL, VALUE IS ZERO. 000079 01 SIP SIZE IS LITTLE, VALUE IS 'SSSLUP'. 000080 01 SLUMBERLAND SIZE IS UNLIMITED, VALUE IS ZZZZZZZZZZ. 000081 CONSTANT SECTION. 000082 01 COMMENT1 PIC X(36) 000083 VALUE 'SOMEBODY HAS BEEN EATING MY PORRIDGE'. 000084 01 COMMENT2 PIC X(36) 000085 VALUE 'SOMEBODY HAS BEEN SLEEPING IN MY BED'. 000086 000087 000088 000089 PROCEDURE DIVISION. 000090 FOREST SECTION. 000091 START-OF-TALE. 000092 OPEN STORY. READ FOLLOWING. 000093 FIRST-MOVE. 000094 MOVE GOLDILOCKS TO COTTAGE. 000095 IF DOOR IS CLOSED OR BEARS ARE GREATER THAN ZERO 000096 ALTER ENTER-GOLDILOCKS TO PROCEED TO HASTY-RETREAT. 000097 ENTER-GOLDILOCKS. 000098 GO TO KITCHEN-SCENE. 000099 KITCHEN-SCENE. 000100 IF PORRIDGE = KING-SIZE 000101 PERFORM TASTE-ROUTINE 000102 VARYING PORRIDGE FROM KING-SIZE BY 1 000103 UNTIL PORRIDGE = PRINCE-SIZE 000104 ELSE 000105 COMPUTE IF COTTAGE = RIGHT-COTTAGE. 000106 GO TO BEDROOM-SCENE. 000107 TASTE-ROUTINE. 000108 SUBTRACT SIP FROM PORRIDGE (KING-SIZE). 000109 SUBTRACT SIP FROM PORRIDGE (QUEEN-SIZE). 000110 SUBTRACT SIP FROM PORRIDGE (PRINCE-SIZE) GIVING NO-PORRIDGE. 000111 BEDROOM-SCENE. 000112 MOVE GOLDILOCKS TO BEDROOM. 000113 ADD GOLDILOCKS TO BED (LARGE). 000114 DISPLAY 'IT IS TOO HARD'. 000115 SUBTRACT GOLDILOCKS FROM BED (LARGE) 000116 GIVING KING-SIZE-BED-SLEPT-IN. 000117 MOVE GOLDILOCKS TO BED (MEDIUM). 000118 DISPLAY 'IT IS TOO SOFT'. 000119 SUBTRACT GOLDILOCKS FROM BED (MEDIUM) 000120 GIVING QUEEN-SIZE-BED-SLEPT-IN. 000121 MOVE GOLDILOCKS TO BED (SMALL). 000122 DISPLAY 'IT IS JUST RIGHT'. 000123 ADD GOLDILOCKS TO SLUMBERLAND. 000124 BEARS-RETURN. 000125 MOVE DADDY-BEAR, MUMMY-BEAR, BABY-BEAR TO KITCHEN. 000126 MOVE CORRESPONDING BEARS TO PORRIDGE. 000127 DISPLAY 'DADDY BEAR', COMMENT1. 000128 DISPLAY 'MUMMY BEAR', COMMENT1. 000129 DISPLAY 'BABY BEAR', COMMENT1, 'AND EATEN IT ALL UP'. 000130 MOVE BEARS TO BEDROOM. 000131 BEARS-IN-BEDROOM. 000132 INSPECT BEDS REPLACING ALL GOLDILOCKS BY BEARS. 000133 DISPLAY 'DADDY BEAR', COMMENT2. 000134 DISPLAY 'MUMMY BEAR', COMMENT2. 000135 DISPLAY 'BABY BEAR', COMMENT2, 'AND HERE SHE IS'. 000136 HASTY-RETREAT. 000137 IF WINDOW IS OPEN 000138 EXIT GOLDILOCKS 000139 ELSE 000140 MOVE GOLDILOCKS TO DOOR. 000141 EXIT. 000142 END. 000143 CLOSE STORY. 000144 DISPLAY 'WOULD YOU BELIEVE CINDERELLA IN PL/I'. 000145 END TALE. 000146* "THE COMMON BUSINESS-ORIENTED GOLDILOCKS" BY PHILIP STANLEY 000147* (CONVERTED TO ANSI74 BY CHARLIE GIBBS) From hnsngr@sirius.com Mon Jun 26 11:36:16 CDT 1995 Article: 105910 of alt.folklore.computers Xref: uchinews alt.folklore.computers:105910 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!news.sprintlink.net!news.zeitgeist.net!sun.sirius.com!slip4032.sirius.com!user From: hnsngr@sirius.com (Ron Hunsinger) Newsgroups: alt.folklore.computers Subject: Re: Reverse Polish Notati Date: Sat, 24 Jun 1995 13:22:18 -0700 Organization: ErsteSoft Lines: 139 Distribution: world Message-ID: References: <1995Jun22.201855.15624@forte.com> <95062323161618401@nwcs.org> NNTP-Posting-Host: slip4032.sirius.com Status: R In article <95062323161618401@nwcs.org>, paul.rogers@nwcs.org (Paul Rogers) wrote: > Processor instructions are easy to wire into hardware because there are > no complex addressing modes. In fact, stack machines are very RISCy; > simple instructions easy to execute. And Burroughs machines were quite > fast, even though they had what seems a strange set of facilities by > modern standards offered by their Master Control Program. They are a > natural for LISP, but for Burroughs the lowest level language was Algol; > there was NO assembler. The instruction set was in fact designed with Algol very much in mind. Algol was designed first and foremost as a publication language, one that researchers could translate their algorithms into for publication in academic journals with some hope that other researchers, working on other machines with entirely different architectures, could nevertheless understand and compare to their own algorithms. If Algol could be compiled, so much the better. But that wasn't the main design goal. In fact, Algol 60 has several features that make it quite challenging to compile. Recursive procedures, for example, are difficult to implement without a stack, and in 1960 you were lucky if your machine had any index registers, let alone a stack pointer. Even with a stack, it wasn't obvious how to handle nesting and recursion at the same time. Edsgar Dijkstra came up with a method using a large bank of index registers, which he called the Display, each pointing to what we would now call a stack frame. He also suggested an alternative method using a much smaller Display (i.e., fewer registers). Of course, nowadays stack frames and frame pointers are pretty much a given, and every machine under the sun provides support for them. But you have to remember that the concept was not always around. Somebody had to think of it first, and to do that you had to get over the mental hurdle of accepting that it might be okay if everything was addressed using index registers. (Absolute addressing is so much faster than indexing that it's hard to imagine using indexing as the norm.) Dijkstra was the first to publish the idea. Burroughs hired him as a Research Fellow to help them design a machine around the concept. The first implementation, using the minimal-display approach, was the B5000. The display consisted of 2 registers: D0 pointed to your globals, and D1 pointed to your local stack frame. (On the Macintosh, the registers A5 and A6 serve the same function.) The XALGOL compiler would not let you refer to variables at intermediate lexicographic levels. (If procedure FOO was nested inside procedure BAR, FOO could see its own variables and global variables, but not any of BAR's variables.) Experience showed that this was not satisfactory. The full display was implemented in the B6500, with a 32-register Display (registers D0..D31), allowing direct access to up to 32 stack frames. This meant you could nest your procedures up to 32 levels deep, and still access variables at every nesting level. (We're talking about static or lexical nesting here, not recursion or dynamic nesting. The latter is limited only by memory.) 32 levels is excessive, and the A-series models cut this back to 16 levels. Nobody missed the top 16 D-registers, which had essentially been collecting electronic dust all those years except on the rare occasion when an engineer ran a diagnostic routine to check that they were still there. But hardware support for Algol did not stop there. Consider the so-called 'thunk'. In Algol, parameters can be passed by value or by name. By-name is not the same as by-reference (although it can be used for that, and usually is). You can pass an expression by name, and if you do, it is the expression itself (not its value, and certainly not its address, for it has none) that is being passed. This lets you write a generalized dot-product routine as: REAL PROCEDURE DOT (I, IBEG, IEND, X, Y); VALUE IBEG, IEND; COMMENT anything not by value is by name; REAL I, IBEG, IEND, X, Y; COMMENT REAL is faster than INTEGER; BEGIN REAL SUM; SUM := 0; FOR I := IBEG STEP 1 UNTIL IEND DO SUM := SUM + X * Y; DOT := SUM; END DOT; and then use it as in: REAL ARRAY A, B, C [0:9, O:9]; REAL I, J, K; ... COMMENT matrix multiplication: C := A * B; FOR I := 0 STEP 1 UNTIL 9 DO FOR J := 0 STEP 1 UNTIL 9 DO C[I,J] := DOT (K, 0, 9, A[I,K], B[K,J]); Notice the feedback. When DOT changes the value of parameter I, it is really changing the value of the caller's K, which changes the meanings of the expressions A[I,K] and B[K,J], which correspond to the formal parameters X and Y. Each reference to X or Y causes the expression which is the actual parameter to be re-evaluated IN THE CONTEXT OF THE CALLER. In particular, the I that appears in the expression A[I,K] is the I of the caller's scope, not the I of DOT's scope. The compiler handles this by writing a 'thunk', or hidden procedure, which evaluates the expression. In this case, the expression is what in C would be called an lvalue, so the thunk for A[I,K] actually computes the address of the specified element of the array. The address of the thunk is then passed to the procedure. (Actually, it's the address of the address of the procedure, but that's another story.) In the procedure, the code to evaluate SUM := SUM + X * Y gets the value of X using an ordinary VALC X (value call) instruction, which simply says: push the value at X onto the stack. The hardware does the rest. The 'value' at X isn't a value at all, it's an address. So the hardware automatically dereferences it. (Every word is tagged, so the hardware can tell what kind of thing it contains.) In this case, the address is the address of code, so the only way to derefence it is to call it as a procedure. The hardware does so, automatically fixing up the Display so that the thunk can see what it should (but can't see any of DOT's local variables). When the procedure returns (restoring the Display so DOT can see what it should), the hardware tries to finish the value call instruction, and notices that it still has an address, which it must try again to dereference. This time, the address points to data, so it succeeds, loading the value of A[I,K] to the stack. A more detailed look at the steps the hardware goes through to make this work reveals a truly beautiful dance. This machine only gets more beautiful the deeper you delve under the covers. Especially when you consider that DOT and its caller do not have to have any particular lexical relationship to each other. They could even be (nested in scopes) in separate processes, but the hardware can still figure out how to adjust the display on the fly so that each executes in the proper environment. I mention all this to show that, while a stack machine can be pretty RISCy, and the Burroughs large system computers are stack machines, they are nevertheless quite CISCy. (BTW: It's true. There really is no assembler. After I became familiar with the machine, I realized that I wouldn't use an assembler even if there were one. Algol is the right language for this machine.) -Ron Hunsinger From uchinews!uwvax!uwm.edu!cs.utexas.edu!uunet!spcuna!spcvxb!terry Fri Oct 15 13:47:30 CDT 1993 Article: 49991 of alt.folklore.computers Newsgroups: alt.folklore.computers Path: uchinews!uwvax!uwm.edu!cs.utexas.edu!uunet!spcuna!spcvxb!terry From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Subject: Re: GWBASIC? Nntp-Posting-Host: spcvxa.spc.edu References: <29l3um$9hd@samba.oit.unc.edu> <29l5df$pql@tamsun.tamu.edu> Sender: news@spcuna.spc.edu (Network News) Organization: St. Peter's College, US Date: Fri, 15 Oct 1993 07:28:35 GMT Message-ID: <1993Oct15.032835.1@spcvxb.spc.edu> Lines: 40 Status: R In article <29l5df$pql@tamsun.tamu.edu>, eag5410@tamsun.tamu.edu (Eugene Austin III Gibbs) writes: > The name for GWBASIC come, and I kid you not, from Gee-Whiz BASIC. It > is the successor to BASICA, or BASIC Advanced. It's stranger than that. IBM wanted resident BASIC in the IBM PC, but only allocated enough code space for 32Kb. (from segments F000 through F7FF). Due to "code bloat" in the machine translation of CP/M BASIC to the 808x, not all of the interpreter (with graphics extensions) could fit in the 32Kb space. So, a limited version of the interpreter with only cassette I/O and other features stripped out went in the ROM, along with "hooks" to allow the code to be augmented/replaced by additional code loaded from disk. Also, this work was done in a bit of a rush (the first few PC's sold needed to be retrofitted because of an error in the math routines). The final version of this code was Version 1.10 from 25-Apr-81. IBM's deal with Microsoft gave them access to this code, but not the right to modify it, for subsequent products. That's why the code stayed at F000 even after the BIOS expanded to below F000 as well as above F800. The MS-DOS BASIC command added disk I/O to the ROM code. BASICA added the advanced functions. GWBASIC (which is indeed "Gee Whiz BASIC") never had the split code architecture of the ROM/BASICA design. It was compatible and shared the same tokenization, but was updated with fixes even after ROM BASIC was frozen. GWBASIC was then backported to the Z-80 for the Spectravideo 318/325 series of computers (later to be the MSX I "standard"). Despite the fact that the Spectravideo ran the Z-80 at 3.58Mhz and the PC ran the 8088 at 4.77Mhz, the Spectravideo was faster than the PC. The two versions weren't 100 percent binary compatible, although I did some work on this and got them pretty close. Unfortunately, the Spectravideo folks were in a big hurry to go to masked ROMs, so almost all of the 318/325 systems out there had a buggy version of BASIC in them. By the way, the MS-DOS disk structure (DOS 1.0) is the same as that of the stand-alone (non-CP/M-based) Microsoft Disk Basic for the 8080. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 From macrakis@osf.org Sun Sep 10 16:21:30 CDT 1995 Article: 114660 of alt.folklore.computers Xref: uchinews alt.folklore.computers:114660 alt.sys.pdp10:733 Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!swrinde!sdd.hp.com!bone.think.com!paperboy.osf.org!paperboy!macrakis From: macrakis@osf.org (Stavros Macrakis) Newsgroups: alt.folklore.computers,alt.sys.pdp10 Subject: Re: old powerful cryptic language (DEC) Date: 08 Sep 1995 18:42:34 GMT Organization: OSF Research Institute Lines: 18 Message-ID: References: <42ikac$e2p$1@sydney.DIALix.oz.au> <42nbnp$drq@ninja.zso.dec.com> <42o36u$al3@ixnews7.ix.netcom.com> NNTP-Posting-Host: app3.osf.org In-reply-to: mcknighl@ix.netcom.com's message of Fri, 08 Sep 1995 00:33:16 GMT Status: R In article <42o36u$al3@ixnews7.ix.netcom.com> mcknighl@ix.netcom.com (Lawrence E. McKnight) writes: Well, years ago I knew somebody who claimed that he had written a LISP interpreter in TECO, just to show it could be done. You can write a basic Lisp interpreter in just about any language very easily. In string-based languages like Teco, it is sometimes easiest to represent S-expressions by their print representations, as long as you don't allow RPLACA/D. As a matter of fact, I once wrote a Lisp-to-Teco compiler (in Lisp, of course), and cross-compiled the first version, giving a Lisp compiler in Teco. But that was ITS Teco with its many extensions -- the motivation was to be able to use Lisp as an extension language as in Multics Emacs based on Maclisp. This was before Emacs was based on Lisp. -s From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!mach.amtp.cam.ac.uk!M.J.Jennings Thu Aug 4 13:33:43 CDT 1994 Article: 73168 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!lyra.csx.cam.ac.uk!mach.amtp.cam.ac.uk!M.J.Jennings From: M.J.Jennings@amtp.cam.ac.uk (Michael Jennings) Newsgroups: alt.folklore.computers Subject: Re: "Hello, world!" programs in different languages ??? Date: 3 Aug 1994 22:25:16 GMT Organization: University of Cambridge, DAMTP Lines: 38 Message-ID: <31p5gc$k5k@lyra.csx.cam.ac.uk> References: <31lal9$2sf@foobar.hanse.de> <31p1de$ivu@sefl.satelnet.org> NNTP-Posting-Host: mach.amtp.cam.ac.uk Status: R In article badger@phylo.life.uiuc.edu (Jonathan Badger) writes: >FORTH: > C, Fortran and /bin/sh: ---CUT HERE--- cat =13 /*/ >/dev/null 2>&1; echo "Hello, world!"; exit * * This program works under cc, f77, and /bin/sh. * */; main() { write( cat-~-cat /*,'( */ ,"Hello, world!" , cat); putchar(~-~-~-cat); } /* ,)') end */ ---CUT HERE--- This one is from the Obfuscated C contest in about 1986 and was written by Jack Applin. -- Michael Jennings Department of Applied Mathematics and Theoretical Physics The University of Cambridge. mjj12@damtp.cambridge.ac.uk Some have a style That they work hard to refine So they walk a crooked line But she won't understand Why anyone would have to try To walk a line when they could fly - The Bangles. From uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!uunet!mdisea!not-for-mail Thu Aug 4 13:36:24 CDT 1994 Article: 73184 of alt.folklore.computers Path: uchinews!vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!uunet!mdisea!not-for-mail From: mitchell@mdd.comm.mot.com (Bill Mitchell) Newsgroups: alt.folklore.computers Subject: Re: "Hello, world!" programs in different languages ??? Date: 3 Aug 1994 18:28:34 -0700 Organization: Motorola - Wireless Data Group; Seattle, WA Lines: 104 Sender: mitchell@mdd.comm.mot.com (Bill Mitchell) Distribution: na Message-ID: <31pg82$2fa@bb29c.mdd.comm.mot.com> References: <31lal9$2sf@foobar.hanse.de> Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell) NNTP-Posting-Host: bb29c.mdd.comm.mot.com Status: R Seeing the title of this thread, I just had to repost this once again: From: peril@extro.ucc.su.OZ.AU (Peter Lisle) Newsgroups: rec.puzzles,comp.lang.misc,alt.folklore.computers Subject: A polyglot program Date: 18 Mar 91 13:19:07 GMT A little while ago some people were talking about polyglot programs in rec.puzzles, these are programs that are written in several languages. We thought it sounded like fun so we wrote this one. Our friends suggested we should post it -- so here it is, let us know what you think. -------- cut here (keep the blank lines: they are important) -------- (*O/*_/ Cu #%* )pop mark/CuG 4 def/# 2 def%%%%@@P[TX---P\P_SXPY!Ex(mx2ex("SX!Ex4P)Ex= CuG #%* *+Ex= CuG #%*------------------------------------------------------------------*+Ex= CuG #%* POLYGLOT - a program in seven languages 15 February 1991 *+Ex= CuG #%* *+Ex= CuG #%* Written by Kevin Bungard, Peter Lisle, and Chris Tham *+Ex= CuG #%* *+Ex= CuG #%* We have successfully run this program using the following: *+Ex= CuG #%* ANSI COBOL: MicroFocus COBOL85 (not COBOL74) *+Ex= CuG #%* ISO Pascal: Turbo Pascal (DOS & Mac), Unix PC, *+Ex= CuG #%* AIX VS Pascal *+Ex= CuG #%* ANSI Fortran: Unix f77, AIX VS Fortran *+Ex= CuG #%* ANSI C (lint free): Microsoft C, Unix CC, GCC, Turbo C++, *+Ex= CuG #%* Think C (Mac) *+Ex= CuG #%* PostScript: GoScript, HP/Adobe cartridge, *+Ex= CuG #%* Apple LaserWriter *+Ex= CuG #%* Shell script: gnu bash, sh (SysV, BSD, MKS), ksh *+Ex= CuG #%* 8086 machine language: MS-DOS 2.00, 3.03, 4.01, 5.00 beta *+Ex= CuG #%* VPix & DOS Merge (under unix) *+Ex= CuG #%* SoftPC (on a Mac), MKS shell *+Ex= CuG #%* *+Ex= CuG #%* Usage: *+Ex= CuG #%* 1. Rename this file to polyglot.[cob|pas|f77|c|ps|sh|com] *+Ex= CuG #%* 2. Compile and/or run with appropriate compiler and *+Ex= CuG #%* operating system *+Ex= CuG #%* *+Ex= CuG #%* Notes: *+Ex= CuG #%* 1. We have attempted to use only standard language features. *+Ex= CuG #%* Without the -traditional flag gcc will issue a warning. *+Ex= CuG #%* *+Ex= CuG #%* 2. This text is a comment block in all seven languages. *+Ex= CuG #%* *+Ex= CuG #%* 3. When run as a .COM file with MS-DOS it makes certain *+Ex= CuG #%* (not unreasonable) assumptions about the contents of *+Ex= CuG #%* the registers. *+Ex= CuG #%* *+Ex= CuG #%* 4. When transfering from Unix to DOS make sure that a LF *+Ex= CuG #%* is correctly translated into a CR/LF. *+Ex= CuG #%* *+Ex= CuG #%* Please mail any comments, corrections or additions to *+Ex= CuG #%* peril@extro.ucc.su.oz.au *+Ex= CuG #%* *+Ex= CuG #%*------------------------------------------------------------------*QuZ= CuG #%* *+Ex= CuG #%*!Mx)ExQX4ZPZ4SP5n#5X!)Ex+ExPQXH,B+ExP[-9Z-9Z)GA(W@'UTTER_XYZZY'CPK*+ CuG #(* *( C # */); /*( C # *) program polyglot (output); (*+ C # identification division. C # program-id. polyglot. C # C # data division. C # procedure division. C # C # * ))cleartomark /Bookman-Demi findfont 36 scalefont setfont ( C # * ( C # C # * hello polyglots$ C # main. C # perform C * ) 2>_$$; echo "hello polyglots"; rm _$$; exit print C stop run. -*, 'hello polyglots' C C print. C display "hello polyglots". ( C */ int i; /* C */ main () { /* C */ i=printf ("hello polyglots\n"); O= &i; return *O; /* C *) (* C *) begin (* C *) writeln ('hello polyglots'); (* C *) (* ) C * ) pop 60 360 ( C * ) pop moveto (hello polyglots) show ( C * ) pop showpage (( C *) end .(* ) C)pop% program polyglot. *){*/} ------------------------------ cut here -------------------------------------- -- mitchell@mdd.comm.mot.com (Bill Mitchell) From uchinews!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!watsun.cc.columbia.edu!lasner Wed Feb 19 12:40:07 CST 1992 Article: 18439 of alt.folklore.computers Path: uchinews!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.folklore.computers Subject: Re: Native (programming) languages of OSes Message-ID: <1992Feb19.180342.26182@cunixf.cc.columbia.edu> Date: 19 Feb 92 18:03:42 GMT References: <1992Feb19.063237.3059@cunixf.cc.columbia.edu> <1992Feb19.071933.8008@cunixf.cc.columbia.edu> <1992Feb19.160410.8214@mintaka.lcs.mit.edu> Sender: usenet@cunixf.cc.columbia.edu (The Network News) Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University Lines: 60 Nntp-Posting-Host: watsun.cc.columbia.edu Status: R We finally get to the heart of the matter, which is that no one here KNOWS what microsoft is using to develop the stuff in. In point of fact, I have had personal contact with individuals and FOAF's who actually did work for the big MS. The original MASM was not written in C, nor was LINK. The source code for the system, which has leaked in older versions, is 100% compatible with older versions, because all parties are afraid to change anything :-). If you ask anyone who has disassembled MSDOS.SYS and/or IO.SYS (I have encountered 3 unrelated individuals who all did this for various versions) you notice that code is implemented clearly in assembly language with absolute patches to add in more code for newer feature This is clearly not C code in any sense. Without resorting to hex constants or such, I defy you to write coherent code in C that accomplishs the code in use, etc. More recently, little actual work has been done on MS-DOS at MS. Note that there is little change in MS-DOS 5 over 4.01, which in turn ain't much more than 3.3. Version 4.01 is largely the effort of IBM employees at the time using the PC-DOS/MS-DOS source files from 3.3. Back then, the two companies were cooperating in their DOS efforts, and files freely exchanged, etc. Eventually, most of the people still in the project were shuffled off to MS, where a faint-hearted effort produced 5.0. This was reported in the trade paper in part to soften the blow about the actual large break developing between MS and IBM. Furthermore, note that the largest amount of code added on to MS-DOS 5 consists of third-party add-ons from Central-Point Software. See their PC-Tools ads which explains it. Quite a lot of noise and hoopla over what actually is little more than some modest improvements added by IBM, Phoenix, etc., C-P S add-ons, and some bug fixes (BTW, there are some bugs introduced in 4 still present in 5, absent in 3.) As a matter of company policy, MS has decreed that all code wherever possible be written in C, apparently in support of the "big move" to another platform planned in the eventual future. However, management was obviously informed this was unworkable for the kernal of the system itself, so MASM code is still the norm. As another poster pointed out, ATTRIB utility is unchanged, yet takes a lot more space because it was rewritten in C with no benefit. So, regardless of what the development system anyone has seen MS "displaying" for semi-public purposes, the bulk of the work was accomplished long before the fancy development system existed. Perhaps the problem is that C programmers need the most "hand-holding" development tools and are the least productive? (This is not a complaint made against the programming community at large, rather just the motley crue that was hired back then by MS :-).) Without getting into specifics, the word from the ex-MS people I have had either direct or FOAF contact with, is that the company is riddled with types who couldn't have gotten the original stuff up if their life depended on it. :-). (And this is part of why they left.) cjl (keeper of various flames) From mitchell@mdd.comm.mot.com Mon Apr 1 12:55:19 CST 1996 Article: 138194 of alt.folklore.computers Xref: uchinews alt.folklore.computers:138194 Path: uchinews!condor.acc.iit.edu!chi-news.cic.net!news.math.psu.edu!psuvax1!news.cc.swarthmore.edu!netnews.upenn.edu!msunews!uwm.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!in2.uu.net!nwnews.wa.com!nwfocus.wa.com!news-wa16!not-for-mail From: mitchell@mdd.comm.mot.com (Bill Mitchell) Newsgroups: alt.folklore.computers Subject: Re: Duff's device Date: 30 Mar 1996 20:37:03 -0800 Organization: Motorola - Wireless Data Group; Seattle, WA Lines: 242 Sender: mitchell@mdd.comm.mot.com (Bill Mitchell) Distribution: na Message-ID: <4jl25f$1im@bb29c.mdd.comm.mot.com> References: <4jj15q$kap@booboo.cs.ucsb.edu> Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell) NNTP-Posting-Host: bb29c.mdd.comm.mot.com Status: R in alt.folklore.computers, ghughes@cs.ucsb.edu (Graham C. Hughes) said: >So why did he do it? Following is an explanation I've got sitting around from a go-round of a Duff's Device thread some years back: Article 16921 of comp.lang.c: Path: mdisea!uw-coco!uw-beaver!micro-heart-of-gold.mit.edu!wupost!spool.mu.edu!yale.edu!jvnc.net!netnews.upenn.edu!netnews!mjd From: mjd@saul.cis.upenn.edu (Sievan Janacek) Newsgroups: comp.lang.c Subject: This is Duff's Device Message-ID: Date: 24 May 92 20:50:40 GMT Article-I.D.: saul.MJD.92May24165040 Sender: news@netnews.upenn.edu Followup-To: comp.misc Organization: Eaters of Wisdom Lines: 172 Nntp-Posting-Host: saul.cis.upenn.edu The two posts that followare Duff's original `Duff's Device' mail and a commentary he wrote some years later after the first time it had been discussed to death in this group. Since then it's been discussed to death several times here, so please, if you must follow up, take followups to comp.misc. ---- Subject: Re: Explanation, please! Summary: Original citation From: td@alice.UUCP (Tom Duff) Organization: AT&T Bell Laboratories, Murray Hill NJ Date: 29 Aug 88 20:33:51 GMT Message-ID: <8144@alice.UUCP> I normally do not read comp.lang.c, but Jim McKie told me that ``Duff's device'' had come up in comp.lang.c again. I have lost the version that was sent to netnews in May 1984, but I have reproduced below the note in which I originally proposed the device. (If anybody has a copy of the netnews version, I would gratefully receive a copy at research!td or td@research.att.com.) To clear up a few points: 1) The point of the device is to express general loop unrolling directly in C. People who have posted saying `just use memcpy' have missed the point, as have those who have criticized it using various machine-dependent memcpy implementations as support. In fact, the example in the message is not implementable as memcpy, nor is any computer likely to have an memcpy-like idiom that implements it. 2) Somebody claimed that while the device was named for me, I probably didn't invent it. I almost certainly did invent it. I had definitely not seen or heard of it when I came upon it, and nobody has ever even claimed prior knowledge, let alone provided dates and times. Note the headers on the message below: apparently I invented the device on November 9, 1983, and was proud (or disgusted) enough to send mail to dmr. Please note that I do not claim to have invented loop unrolling, merely this particular expression of it in C. 3) The device is legal dpANS C. I cannot quote chapter and verse, but Larry Rosler, who was chairman of the language subcommittee (I think), has assured me that X3J11 considered it carefully and decided that it was legal. Somewhere I have a note from dmr certifying that all the compilers that he believes in accept it. Of course, the device is also legal C++, since Bjarne uses it in his book. 4) Somebody invoked (or more properly, banished) the `false god of efficiency.' Careful reading of my original note will put this slur to rest. The alternative to genuflecting before the god of code-bumming is finding a better algorithm. It should be clear that none such was available. If your code is too slow, you must make it faster. If no better algorithm is available, you must trim cycles. 5) The same person claimed that the device wouldn't exhibit the desired speed-up. The argument was flawed in two regards: first, it didn't address the performance of the device, but rather the performance of one of its few uses (implementing memcpy) for which many machines have a high-performance idiom. Second, the poster made his claims in the absence of timing data, which renders his assertion suspect. A second poster tried the test, but botched the implementation, proving only that with diligence it is possible to make anything run slowly. 6) Even Henry Spencer, who hit every other nail square on the end with the flat round thing stuck to it, made a mistake (albeit a trivial one). Here is Henry replying to bill@proxftl.UUCP (T. William Wells): >>... Dollars to doughnuts this code >>was written on a RISC machine. >Nope. Bell Labs Research uses VAXen and 68Ks, mostly. I was at Lucasfilm when I invented the device. 7) Transformations like this can only be justified by measuring the resulting code. Be careful when you use this thing that you don't unwind the loop so much that you overflow your machine's instruction cache. Don't try to be smarter than an over-clever C compiler that recognizes loops that implement block move or block clear and compiles them into machine idioms. Here then, is the original document describing Duff's device: >From research!ucbvax!dagobah!td Sun Nov 13 07:35:46 1983 Received: by ucbvax.ARPA (4.16/4.13) id AA18997; Sun, 13 Nov 83 07:35:46 pst Received: by dagobah.LFL (4.6/4.6b) id AA01034; Thu, 10 Nov 83 17:57:56 PST Date: Thu, 10 Nov 83 17:57:56 PST From: ucbvax!dagobah!td (Tom Duff) Message-Id: <8311110157.AA01034@dagobah.LFL> To: ucbvax!decvax!hcr!rrg, ucbvax!ihnp4!hcr!rrg, ucbvax!research!dmr, ucbvax!research!rob Consider the following routine, abstracted from code which copies an array of shorts into the Programmed IO data register of an Evans & Sutherland Picture System II: send(to, from, count) register short *to, *from; register count; { do *to = *from++; while(--count>0); } (Obviously, this fails if the count is zero.) The VAX C compiler compiles the loop into 2 instructions (a movw and a sobleq, I think.) As it turns out, this loop was the bottleneck in a real-time animation playback program which ran too slowly by about 50%. The standard way to get more speed out of something like this is to unwind the loop a few times, decreasing the number of sobleqs. When you do that, you wind up with a leftover partial loop. I usually handle this in C with a switch that indexes a list of copies of the original loop body. Of course, if I were writing assembly language code, I'd just jump into the middle of the unwound loop to deal with the leftovers. Thinking about this yesterday, the following implementation occurred to me: send(to, from, count) register short *to, *from; register count; { register n=(count+7)/8; switch(count%8){ case 0: do{ *to = *from++; case 7: *to = *from++; case 6: *to = *from++; case 5: *to = *from++; case 4: *to = *from++; case 3: *to = *from++; case 2: *to = *from++; case 1: *to = *from++; }while(--n>0); } } Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this discovery. If no one's thought of it before, I think I'll name it after myself. It amazes me that after 10 years of writing C there are still little corners that I haven't explored fully. (Actually, I have another revolting way to use switches to implement interrupt driven state machines but it's too horrid to go into.) Many people (even bwk?) have said that the worst feature of C is that switches don't break automatically before each case label. This code forms some sort of argument in that debate, but I'm not sure whether it's for or against. yrs trly Tom -- And for to see, and eke for to be seye Mark-Jason Dominus mjd@central.cis.upenn.edu Article 4975 of comp.misc: Newsgroups: comp.misc Path: mdisea!mdivax1!van-bc!ubc-cs!destroyer!caen!sdd.hp.com!mips!mips!munnari.oz.au!metro!mama!greyham From: greyham@research.canon.oz.au (Graham Stoney) Subject: Re: This is Duff's Device Message-ID: <1992May27.062343.12981@research.canon.oz.au> Sender: news@research.canon.oz.au Organization: Canon Information Systems Research Australia References: Date: Wed, 27 May 1992 06:23:43 GMT Lines: 30 mjd@saul.cis.upenn.edu (Sievan Janacek) writes: >The two posts that followare Duff's original `Duff's Device' mail and a >commentary he wrote some years later after the first time it had been >discussed to death in this group. And in the quote Tom Duff says: >To clear up a few points: >1) The point of the device is to express general > loop unrolling directly in C. People who have > posted saying `just use memcpy' have missed the > point... And later Tom is quoted saying: > Of course, > the device is also legal C++, since Bjarne uses it in > his book. But does he?. Yes, it's the same loop-unrolling construct, but at least in the 1987 edition (to quote Tom Duff) Bjane Stroustrup has "missed the point", since the "Duff's device" in example 10, chapter 3 does a copy rather than IO to a fixed data register. Sounds like Bjarne made the common mistake of thinking Duff's device did a memory copy, and Tom mistakenly thought Bjarne reproduced it "correctly" (or the example mutated between book revisions). -- Graham Stoney. Ph: +61 2 805-2909 Fax: -2929 "a Perl script is correct if it's halfway readable | Larry Wall & and gets the job done before your boss fires you." | Randal Schwartz -- mitchell@mdd.comm.mot.com (Bill Mitchell)