From w.f.j.mueller at retro11.de Tue Jun 6 00:12:47 2017 From: w.f.j.mueller at retro11.de (Walter F.J. Mueller) Date: Mon, 5 Jun 2017 16:12:47 +0200 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh Message-ID: Hi, I'm using 211bsd (Version 447) and found that a 'here document' in tcsh leads to a kernel panic. It's absolutely reproducible on my system, both when run it on my FPGA PDP-11 or in simh. Just doing tcsh cat << EOF is enough, and I get ka6 31333 aps 147472 pc 161324 ps 30004 ov 4 cpuerr 20 trap type 0 panic: trap syncing disks... done looking at the crash dump gives cd /etc/crash ./why 4 Backtrace: 0147372: _boot(05000,0100) from ~panic+072 0147414: _etext(011350) from ~trap+0350 0147450: ~trap() from call+040 0147516: _psignal(0101520,0160750) from ~trap+0364 0147554: ~trap() from call+040 so the crash is in psignal, which is afaik the kernel internal mechanism to dispatch signals. Questions: 1. has anybody seen this before ? 2. any idea what the reason could be ? With best regards, Walter From michael at kjorling.se Tue Jun 6 02:16:49 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 5 Jun 2017 16:16:49 +0000 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: References: Message-ID: <20170605161649.GL21406@yeono.kjorling.se> On 5 Jun 2017 16:12 +0200, from w.f.j.mueller at retro11.de (Walter F.J. Mueller): > I'm using 211bsd (Version 447) and found that a 'here document' in tcsh > leads to a kernel panic. It's absolutely reproducible on my system, both > when run it on my FPGA PDP-11 or in simh. Just doing > > tcsh > cat << EOF I'm curious whether the same thing happens if you try that in some other shell? (Not sure how widely here documents were supported back then, but I'm asking anyway.) > is enough, and I get > > ka6 31333 aps 147472 > pc 161324 ps 30004 > ov 4 > cpuerr 20 > trap type 0 > panic: trap > syncing disks... done > > looking at the crash dump gives > > cd /etc/crash > ./why 4 > Backtrace: > 0147372: _boot(05000,0100) from ~panic+072 > 0147414: _etext(011350) from ~trap+0350 > 0147450: ~trap() from call+040 > 0147516: _psignal(0101520,0160750) from ~trap+0364 > 0147554: ~trap() from call+040 > > so the crash is in psignal, which is afaik the kernel internal > mechanism to dispatch signals. The PC value in the panic report ("pc 161324") strikes me as high, but 161324 octal is 58068 decimal, so it's not excessively so, and perhaps in line with what one might expect to see with a kernel pinned near top of memory. Are the offsets in the backtrace constant, i.e. does it always crash on the same code? Not knowing what cpuerr 20 is specifically doesn't help, and at least http://www.retro11.de/ouxr/29bsd/usr/src/sys/sys/trap.c.html#n:112 (which doesn't seem to be too far from what you are running) isn't terribly enlightening; CPUERR is simply a pointer into a memory-mapped register of some kind, as seen at http://www.retro11.de/ouxr/29bsd/usr/include/sys/iopage.h.html#m:CPUERR, and at least pdp11_cpumod.c from the simh source code at http://simh.trailing-edge.com/interim/pdp11_cpumod.c wasn't terribly enlightening, though of course I could be looking in entirely the wrong place. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From ron at ronnatalie.com Tue Jun 6 02:33:22 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 5 Jun 2017 12:33:22 -0400 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: <20170605161649.GL21406@yeono.kjorling.se> References: <20170605161649.GL21406@yeono.kjorling.se> Message-ID: <014101d2de19$7385e870$5a91b950$@ronnatalie.com> Trap type 0 is bus error. The two causes of this are either addressing memory location that does not respond (as opposed to being umapped) or an word operation on an odd address. Since you have a cpuerr print out you have a 44/45/70 CPU. The 020 value indicates that it was the bus timeout case. Something touched memory that was mapped in but didn't physically exist. From jacob.ritorto at gmail.com Tue Jun 6 08:08:08 2017 From: jacob.ritorto at gmail.com (Jacob Ritorto) Date: Mon, 5 Jun 2017 18:08:08 -0400 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: <014101d2de19$7385e870$5a91b950$@ronnatalie.com> References: <20170605161649.GL21406@yeono.kjorling.se> <014101d2de19$7385e870$5a91b950$@ronnatalie.com> Message-ID: Nice snipe, Ron! Where might one find the list of trap_types and cpuerrs? On Mon, Jun 5, 2017 at 12:33 PM, Ron Natalie wrote: > Trap type 0 is bus error. The two causes of this are either addressing > memory location that does not respond (as opposed to being umapped) or an > word operation on an odd address. > > Since you have a cpuerr print out you have a 44/45/70 CPU. The 020 value > indicates that it was the bus timeout case. > > Something touched memory that was mapped in but didn't physically exist. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Jun 6 09:05:23 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 5 Jun 2017 19:05:23 -0400 (EDT) Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh Message-ID: <20170605230523.7A45818C0AA@mercury.lcs.mit.edu> > From: Jacob Ritorto > Where might one find the list of trap_types Look in: http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdp/scb.s which maps from trap vector locations (built into the hardware; consult a PDP-11 CPU manual for details) to trap type numbers, which are defined here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdp/trap.h and handled here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/sys/pdp/trap.c > and cpuerrs? That just prints the contents of the CPU Error Register; see an appropriate PDP-11 CPU manual - 11/70, /44, /73, /83 or /84 for what all the bits mean. Also the "KDJ11-A CPU Module User's Guide", which also documents it. In theory, there's also a KDJ11-B UG, but it's not online. If anyone has one, can we please get it scanned? Thanks! Noel From ron at ronnatalie.com Tue Jun 6 21:43:30 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 6 Jun 2017 07:43:30 -0400 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: References: <20170605161649.GL21406@yeono.kjorling.se> <014101d2de19$7385e870$5a91b950$@ronnatalie.com> Message-ID: <01ef01d2deba$1f469b50$5dd3d1f0$@ronnatalie.com> Chapter 3 of the PDP-11 processor handbook. Crudely scanned copy here: http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf From: Jacob Ritorto [mailto:jacob.ritorto at gmail.com] Sent: Monday, June 5, 2017 6:08 PM To: Ron Natalie Cc: Michael Kjörling; tuhs at minnie.tuhs.org Subject: Re: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh Nice snipe, Ron! Where might one find the list of trap_types and cpuerrs? On Mon, Jun 5, 2017 at 12:33 PM, Ron Natalie wrote: Trap type 0 is bus error. The two causes of this are either addressing memory location that does not respond (as opposed to being umapped) or an word operation on an odd address. Since you have a cpuerr print out you have a 44/45/70 CPU. The 020 value indicates that it was the bus timeout case. Something touched memory that was mapped in but didn't physically exist. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bqt at update.uu.se Wed Jun 7 05:15:23 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Tue, 6 Jun 2017 21:15:23 +0200 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: References: Message-ID: On 2017-06-06 04:00, Michael Kjörling wrote: > > On 5 Jun 2017 16:12 +0200, from w.f.j.mueller at retro11.de (Walter F.J. Mueller): >> I'm using 211bsd (Version 447) and found that a 'here document' in tcsh >> leads to a kernel panic. It's absolutely reproducible on my system, both >> when run it on my FPGA PDP-11 or in simh. Just doing >> >> tcsh >> cat << EOF > I'm curious whether the same thing happens if you try that in some > other shell? (Not sure how widely here documents were supported back > then, but I'm asking anyway.) Not sure if any of the other shells have this. We're basically talking csh, sh and ksh unless I remember wrong. But it's a good question. If noone else have tried it by tomorrow, I could check. >> is enough, and I get >> >> ka6 31333 aps 147472 >> pc 161324 ps 30004 >> ov 4 >> cpuerr 20 >> trap type 0 >> panic: trap >> syncing disks... done >> >> looking at the crash dump gives >> >> cd /etc/crash >> ./why 4 >> Backtrace: >> 0147372: _boot(05000,0100) from ~panic+072 >> 0147414: _etext(011350) from ~trap+0350 >> 0147450: ~trap() from call+040 >> 0147516: _psignal(0101520,0160750) from ~trap+0364 >> 0147554: ~trap() from call+040 >> >> so the crash is in psignal, which is afaik the kernel internal >> mechanism to dispatch signals. > The PC value in the panic report ("pc 161324") strikes me as high, but > 161324 octal is 58068 decimal, so it's not excessively so, and perhaps > in line with what one might expect to see with a kernel pinned near > top of memory. Are the offsets in the backtrace constant, i.e. does it > always crash on the same code? 161324 is way high. This is in kernel mode, and that is in the I/O page. Basically no code lives in the I/O page (some boot roms and hardware diagnostics excepted). This smells like corrupted memory (pointer or stack), or something else very funny. > Not knowing what cpuerr 20 is specifically doesn't help, and at least > http://www.retro11.de/ouxr/29bsd/usr/src/sys/sys/trap.c.html#n:112 > (which doesn't seem to be too far from what you are running) isn't > terribly enlightening; CPUERR is simply a pointer into a memory-mapped > register of some kind, as seen at > http://www.retro11.de/ouxr/29bsd/usr/include/sys/iopage.h.html#m:CPUERR, > and at least pdp11_cpumod.c from the simh source code at > http://simh.trailing-edge.com/interim/pdp11_cpumod.c wasn't terribly > enlightening, though of course I could be looking in entirely the > wrong place. Like others said - the cpu error register is documented in the processor handbook. 020 means Unibus Timeout, which is consistent with trying to access something in the I/O page, where there is no device configured to respond to that address. I just tried the same thing on a simh system here, and I do not get a crash. This on 2.11BSD at patch level 449, running on an emulated 11/94. I do however get tcsh to crash. simh:/home/bqt> su - Password: erase, kill ^U, intr ^C # tcsh simh:/# cat << EOF Illegal instruction - core dumped # Suspended (tty input) simh:/home/bqt> simh:/home/bqt> cat /VERSION Current Patch Level: 448 Date: January 5, 2010 Yes, it says patch level 448, but it really is 449. This was the system where I worked together with Steven when doing the 449 patch set, but I never got around to actually updating the VERSION file itself. Also, this was while running on the console. Could you (Walter) try the latest version of 2.11BSD and see if you still get that crash? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From ag4ve.us at gmail.com Wed Jun 7 22:56:48 2017 From: ag4ve.us at gmail.com (shawn wilson) Date: Wed, 7 Jun 2017 08:56:48 -0400 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: I learned the other day that array indexes in some languages start at 1 instead of 0. This seems to be an old trend that changed around the 70s? Who started this? Why was the change made? It seems to have come about around the same time as C, but interestingly enough Lua is kinda in between (you can start an array at 0 or 1). Smalltalk can probably have a 0 base index just by it's nature, but I wonder whether that would work in a 40 year old interpreter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Jun 7 23:16:33 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 7 Jun 2017 09:16:33 -0400 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: <00d901d2df90$4959c3f0$dc0d4bd0$@ronnatalie.com> The original FORTRAN and BASIC arrays started indexing at one because everybody other than computer scientists start counting at 1. These languages were for scientists and the beginner, so you wanted to make things compatible with their normal concepts. PASCAL on the other hand required you to give the minimum and maximum index for the array. It was an interesting concept when I got into computers in the early seventies that things would be numbered from zero. Tape drive 0, TTY0, etc… Of course, C’s half-assaed implementation of arrays kind of depends on zero-indexing to work. From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of shawn wilson Sent: Wednesday, June 7, 2017 8:57 AM To: The Eunuchs Hysterical Society Subject: [TUHS] Array index history I learned the other day that array indexes in some languages start at 1 instead of 0. This seems to be an old trend that changed around the 70s? Who started this? Why was the change made? It seems to have come about around the same time as C, but interestingly enough Lua is kinda in between (you can start an array at 0 or 1). Smalltalk can probably have a 0 base index just by it's nature, but I wonder whether that would work in a 40 year old interpreter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Jun 7 23:20:43 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 07 Jun 2017 07:20:43 -0600 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: <201706071320.v57DKhmJ026303@freefriends.org> shawn wilson wrote: > I learned the other day that array indexes in some languages start at 1 > instead of 0. This seems to be an old trend that changed around the 70s? > Who started this? Why was the change made? > > It seems to have come about around the same time as C, but interestingly > enough Lua is kinda in between (you can start an array at 0 or 1). > Smalltalk can probably have a 0 base index just by it's nature, but I > wonder whether that would work in a 40 year old interpreter. Basically, until C came along, the standard practice was for indices to start at 1. Certainly Fortran and Pascal did it that way. I suspect that all the Algol family languages did too, but I only did a little Algol W programming in colledge and that was long ago. I think Cobol also. Pascal (IIRC) allowed you to specify upper and lower bounds, something like foo : array[5..10] of integer; with runtime bounds checking on array accesses. (I could be wrong --- it's been a LLLLOOONNNGGG time.) HTH, Arnold From michael at kjorling.se Wed Jun 7 23:50:04 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 7 Jun 2017 13:50:04 +0000 Subject: [TUHS] Array index history In-Reply-To: <201706071320.v57DKhmJ026303@freefriends.org> References: <201706071320.v57DKhmJ026303@freefriends.org> Message-ID: <20170607135004.GB7802@yeono.kjorling.se> On 7 Jun 2017 07:20 -0600, from arnold at skeeve.com: > Basically, until C came along, the standard practice was for indices > to start at 1. Certainly Fortran and Pascal did it that way. I suspect > that all the Algol family languages did too, but I only did a little > Algol W programming in colledge and that was long ago. I think Cobol also. On the other hand, before C, both B and BCPL used zero-based indexing. So if we trace C's family tree, there is certainly precedence for zero-based indexing into arrays. https://www.bell-labs.com/usr/dmr/www/kbman.pdf page 8 (PDF page 10) says: > 7. A vector is a primary expression followed by any expression in [] > brackets. The two expressions are evaluated to rvalues, added and > the result is used as an lvalue. The primary expression can be > thought of as a pointer to the base of a vector, while the bracketed > expression can be thought of as the offset in the vector. Since > E1[E2] is identical to *(E1+E2), and addition is commutative, the > base of the vector and teh offset in the vector can swap positions. And https://www.bell-labs.com/usr/dmr/www/bcpl.pdf page 11 (PDF page 14) says: > 4.7 Vector Applications > /.../ > Semantics: A vector is represented by a pointer to a consecutive > group of words which are the elements of the vector. The pointer > points to the zeroth element. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From arnold at skeeve.com Thu Jun 8 00:02:39 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 07 Jun 2017 08:02:39 -0600 Subject: [TUHS] Array index history In-Reply-To: <20170607135004.GB7802@yeono.kjorling.se> References: <201706071320.v57DKhmJ026303@freefriends.org> <20170607135004.GB7802@yeono.kjorling.se> Message-ID: <201706071402.v57E2dTs032508@freefriends.org> Michael Kjörling wrote: > On the other hand, before C, both B and BCPL used zero-based indexing. > So if we trace C's family tree, there is certainly precedence for > zero-based indexing into arrays. Ah. OK. I never used either language. I get the impression that BCPL wasn't used / known much in the US, but I could be wrong. I was exposed to BASIC and FORTRAN (and computer programming) circa 1976 and to C in 1980. Anything before then is before my time ... :-) Thanks, Arnold From dot at dotat.at Thu Jun 8 00:58:50 2017 From: dot at dotat.at (Tony Finch) Date: Wed, 7 Jun 2017 15:58:50 +0100 Subject: [TUHS] Array index history In-Reply-To: <20170607135004.GB7802@yeono.kjorling.se> References: <201706071320.v57DKhmJ026303@freefriends.org> <20170607135004.GB7802@yeono.kjorling.se> Message-ID: Michael Kjörling wrote: > > And https://www.bell-labs.com/usr/dmr/www/bcpl.pdf page 11 (PDF page > 14) says: > > > 4.7 Vector Applications > > /.../ > > Semantics: A vector is represented by a pointer to a consecutive > > group of words which are the elements of the vector. The pointer > > points to the zeroth element. That syntax is quite different from the later BCPL that I'm familiar with. http://www.cl.cam.ac.uk/~mr10/bcplman.pdf It has a ! indirection operator which can be both unary and binary, as in old BCPL new BCPL C lv x @x &x rv ptr !ptr *ptr ptr*[i] ptr!i ptr[i] Richards' 1969 paper uses a down-arrow for binary ! You can use "manifest" constants for laying out a structure, e.g. MANIFEST { car; cdr; } declares car and cdr to have values 0 and 1. This lets you do struct-style indirection using the same operator as for array indexing, like in this function definition: LET cadr(p) = p!cdr!car; When I saw how ->integ is used in the 6th Edition kernel it felt very BCPL to me. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Shannon: Cyclonic becoming southwest, 5 or 6. Moderate or rough. Rain. Moderate or poor. From lyndon at orthanc.ca Thu Jun 8 02:31:56 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Wed, 7 Jun 2017 09:31:56 -0700 (PDT) Subject: [TUHS] Array index history In-Reply-To: <201706071320.v57DKhmJ026303@freefriends.org> References: <201706071320.v57DKhmJ026303@freefriends.org> Message-ID: > Basically, until C came along, the standard practice was for indices > to start at 1. Certainly Fortran and Pascal did it that way. I suspect > that all the Algol family languages did too, but I only did a little > Algol W programming in colledge and that was long ago. I think Cobol also. APL (excepting some early implementations) lets you set the "index origin" to either 0 or 1, either by assigning a value to the quad-IO system variable, or through the ')ORIGIN' command (varies with the implementation). Changing quad-IO inside a function at runtime was a trick used to inflict endless terror on many a first-year undergrad ;-) --lyndon From tfb at tfeb.org Thu Jun 8 03:59:43 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Wed, 7 Jun 2017 18:59:43 +0100 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: On 7 Jun 2017, at 13:56, shawn wilson wrote: > > I learned the other day that array indexes in some languages start at 1 instead of 0. This seems to be an old trend that changed around the 70s? Who started this? Why was the change made? I was going to make the obvious glib comment about languages which care more about some transient notion of efficiency than usability leading to 0-based indexing. But I think in fact it must be cultural: FORTRAN was historically 1-based, of course, and although it looks like LISP 1 (1960) didn't have arrays, LISP 1.5 (1962) *did*, and they were 0-based. It looks to me like ALGOL 58 allowed you to define lower & upper bounds, based on http://www.softwarepreservation.org/projects/ALGOL/report/Algol58_preliminary_report_CACM.pdf/view So I suspect that languages designed by and for people who actually did a lot of numerical matrix manipulation (ie applied mathematicians, physicists &c) used the conventions of those fields, which were and are 1-based indexing; languages designed by & for formal CS people tended to use zero-based, and languages designed by people who were feeling their oats as regards flexibility allowed user-defined bounds. --tim From clemc at ccc.com Thu Jun 8 04:29:41 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 7 Jun 2017 14:29:41 -0400 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: On Wed, Jun 7, 2017 at 8:56 AM, shawn wilson wrote: > I learned the other day that array indexes in some languages start at 1 > instead of 0. This seems to be an old trend that changed around the 70s? > Who started this? Why was the change made? ​Tastes Change -- but I really think its more "things happen" is the short answer. The longer answer really comes from what you were comfortable. As has been pointed at the 'engineers' and US types that grew up in the world of Fortran and Basic in the 50s, and 60s had used 1. Which made perfect sense for them. Certainly has my father was taught and how he taught me in the sixties. However, the 'formal' mathematician and Europeans types from the Algol world ​tended to think 'normal' in terms of counting from 0 like the HW did during the same time period. By the late 60s, early 70th, as has been pointed out, some languages started to offer some choice. I remember different professors at CMU having different views what was better - and clearly it was a matter of taste. But most took a view of what was most important was to keep *to local custom and convention *as the SW engineering rule* of 'least amazement' *needed to be high bit. I think the more interesting note is that Ken has gone on record to state he set out to create a Fortran compiler when he created B. So it is an interesting question of why B (and C) ended up with the BCPL (Algol) convention of 0 based addresses not the Fortran 1 based? But I actually think the 'zero-ness' of today, we have is less to do with 'Algol-like' (Pascal et al) winning and being 'better' than it was that C ended up as the dominant language and for whatever reason Ken picked zero based addressing - probably >>I'll guess<< because he was staying close to the HW. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Jun 8 04:46:29 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 7 Jun 2017 14:46:29 -0400 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> If you think of an array as a memory area of bytes, words, whatever, the simple way to deal with it is the index being 0 is the first in the array. Why go to the trouble of decrementing the index to retreive the first entry? ALGOL did indeed have arrays with bounds: INTEGER ARRAY K,L[0:10,0:10]; Two arrays, K and L with 0 first, 10 last. Total of 11 elements. Of course, it's a "higher level" language than C. My thinking on the subject is that C is very close to assembler, so if you're using for example Intel X86 instructions: MOV SI,1 MOV AL,[SI + ARRAY1] ; retrieve the SECOND element (byte) Likewise, for words, just left-shift SI one bit. For me having started out in assembler (actually, MACRO-10 on a PDP-10), it's intuitive as to why/how C does arrays. ak From ron at ronnatalie.com Thu Jun 8 05:03:02 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 7 Jun 2017 15:03:02 -0400 Subject: [TUHS] Array index history In-Reply-To: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> Message-ID: <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> > Why go to the trouble of decrementing the index to retreive the first entry? What makes you think that you have to decrement the index. Don't get sucked up in the idiotic C implementation of an array. Arrays can be efficiently implemented no matter where the index starts. From krewat at kilonet.net Thu Jun 8 05:15:05 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 7 Jun 2017 15:15:05 -0400 Subject: [TUHS] Array index history In-Reply-To: <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> Message-ID: <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> On 6/7/2017 3:03 PM, Ron Natalie wrote: >> Why go to the trouble of decrementing the index to retreive the first entry? > What makes you think that you have to decrement the index. Don't get sucked up in the idiotic C implementation of an array. Arrays can be efficiently implemented no matter where the index starts. > > In the days when memory and clock cycles were costly, an extra decrement or subtract was not something to be taken lightly :) On the other hand, I can see that you could solve this in the preprocessor. In my example, just make it: MOV AL, [SI + (ARRAY1 - FIRSTELEMENT)] And let the assembler deal with it. Still, there's something oddly "artificial" about that, again from the machine language point of view. There's nothing "idiotic" about it IMHO. It's just the way processors actually work. Of course, if you're really into abstraction, well, to each his own :) ak From ron at ronnatalie.com Thu Jun 8 05:49:32 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 7 Jun 2017 15:49:32 -0400 Subject: [TUHS] Array index history In-Reply-To: <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> Message-ID: <016f01d2dfc7$2f57e0e0$8e07a2a0$@ronnatalie.com> The memory storage location and the first element offset are effectively constants, you can remove them from the equation. From w.f.j.mueller at retro11.de Thu Jun 8 06:14:07 2017 From: w.f.j.mueller at retro11.de (Walter F.J. Mueller) Date: Wed, 7 Jun 2017 22:14:07 +0200 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh Message-ID: <86b6acb7-93ec-0dbd-b5a1-bd566e8c3cef@retro11.de> Hi, a few remarks on the feedback on the kernel panic after a 'here document' in tcsh. To Michael Kjörling question: > I'm curious whether the same thing happens if you try that in some > other shell? (Not sure how widely here documents were supported back > then, but I'm asking anyway.) And Johnny Billquist remark > Not sure if any of the other shells have this. 'here documents' are available and work fine in sh and csh. And are in fact used, examples /usr/adm/daily (a /bin/sh script) su uucp << EOF /etc/uucp/clean.daily EOF /usr/crash/why (a /bin/csh script) adb -k {unix,core}.$1 << 'EOF' version/sn"Backtrace:"n $c 'EOF' To Michael Kjörling remark > The PC value in the panic report ("pc 161324") strikes me as high and Johnny Billquist remark > This is in kernel mode, and that is in the I/O page. 211bsd uses split I/D space and uses all 64 kB I space for code. The top 8 kB are in fact the overlay area, and the crash happened in overlay 4 (as indicated by ov 4). With a simple nm /unix | sort | grep " 4" one gets 161254 t ~psignal 4 162302 t ~issignal 4 so the crash is just 050 bytes after the entry point of psignal. So the PC address is fine and not the problem. For psignal look at http://www.retro11.de/ouxr/211bsd/usr/src/sys/sys/kern_sig.c.html#s:_psignal the crash must be one of the first lines. psignal is an internal kernel function, called from http://www.retro11.de/ouxr/211bsd/usr/src/sys/sys/kern_sig.c.html#xref:s:_psignal and has nothing to do with the libc function psignal http://www.retro11.de/ouxr/211bsd/usr/man/cat3/psignal.0.html http://www.retro11.de/ouxr/211bsd/usr/src/lib/libc/gen/psignal.c.html To Johnny Billquist remark > Could you (Walter) try the latest version of 2.11BSD and see if you > still get that crash? very interesting that you see a core dump of tcsh rather a kernel panic. Whatever tcsh does, it should not lead to a kernel panic, and if it does, it is primarily a bug of the kernel. It looks like there are two issues, one in tcsh, and one in the kernel. I've a hunch were this might come from, but that will take a weekend or two to check on. With best regards, Walter From dave at horsfall.org Thu Jun 8 09:57:47 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Jun 2017 09:57:47 +1000 (EST) Subject: [TUHS] Array index history In-Reply-To: References: <201706071320.v57DKhmJ026303@freefriends.org> <20170607135004.GB7802@yeono.kjorling.se> Message-ID: On Wed, 7 Jun 2017, Tony Finch wrote: > You can use "manifest" constants for laying out a structure, e.g. > > MANIFEST { car; cdr; } > > declares car and cdr to have values 0 and 1. [...] Which of course led to C's "enum" facility. ` -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From bakul at bitblocks.com Thu Jun 8 10:47:33 2017 From: bakul at bitblocks.com (Bakul Shah) Date: Wed, 07 Jun 2017 17:47:33 -0700 Subject: [TUHS] Array index history In-Reply-To: Your message of "Wed, 07 Jun 2017 07:20:43 MDT." <201706071320.v57DKhmJ026303@freefriends.org> References: <201706071320.v57DKhmJ026303@freefriends.org> Message-ID: <20170608004733.29524124AEC2@mail.bitblocks.com> On Wed, 07 Jun 2017 07:20:43 MDT arnold at skeeve.com wrote: > > Basically, until C came along, the standard practice was for indices > to start at 1. Certainly Fortran and Pascal did it that way. Pascal's array type syntax is array-type: "array" "[" index-type "]" "of" type Index type could be an integer sub-range or scalar type or scalar sub-range. Pascal doesn't allow specifying array size with a simple integer so the question of default index for first element doesn't arise. In spite of having learned and used Pascal, PL/I, Fortran and APL before C, a lower bound of 0 seemed most sensible to me. Not because of any efficiency reasons but because of modular arithmetic which I learned before C! From arjanen.loic at gmail.com Thu Jun 8 11:58:25 2017 From: arjanen.loic at gmail.com (=?UTF-8?Q?ARJANEN_Lo=C3=AFc_Jean_David?=) Date: Thu, 8 Jun 2017 08:58:25 +0700 Subject: [TUHS] Array index history In-Reply-To: <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> Message-ID: Le jeudi 8 juin 2017, Arthur Krewat a écrit : > On 6/7/2017 3:03 PM, Ron Natalie wrote: > >> Why go to the trouble of decrementing the index to retreive the first >>> entry? >>> >> What makes you think that you have to decrement the index. Don't get >> sucked up in the idiotic C implementation of an array. Arrays can be >> efficiently implemented no matter where the index starts. >> >> >> In the days when memory and clock cycles were costly, an extra decrement > or subtract was not something to be taken lightly :) > I doubt that avoiding a decrement was really the reason. I mean, it's an array: if you're 0-basing it you're still paying a decrement but for bounds checking this time. Keeping as close as possible to how the target machine worked or following a convention in another hand, that I can see. Loïc -- ARJANEN Loïc Jean David http://blog.luigiscorner.com --- “Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes. Science is not about tools. It is about how we use them, and what we find out when we do.” Michael R. Fellows and Ian Parberry -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Jun 8 12:27:05 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 07 Jun 2017 22:27:05 -0400 Subject: [TUHS] Array index history Message-ID: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> > Who started this? Why was the change made? Arrays in Fortran and Algol were indexed from 1 by default, but Algol (IIRC) generalized that to allow first:last declarations. NPL used first,last for the SUBSTR operation. But first,last begets off-by-one errors. The successor slice begins at last+1. The formula for the position of 1-indexed a[i,j] is a mess. First,length is much cleaner: the successor begins at first+length. I convinced the committee of that, so when NPL became PL/I, first,length was the convention. Zero- indexing is also a clean first,length notation. BCPL, where a[i] was synonymous with rv(a+i), had it. Dennis, who knew a good thing when he saw it, took it over. Dijkstra, too, often inveighed against 1-indexing, and opined that zero was the true computer-science way. 1-indexing certainly came into programming languages from the math tradition for matrix notation. Of course in math series are often indexed from zero, so one may pick and choose. Off hand I can only think of one CS context where 1 comes in handy: heapsort. Doug From rmswierczek at gmail.com Thu Jun 8 12:45:08 2017 From: rmswierczek at gmail.com (Robert Swierczek) Date: Wed, 7 Jun 2017 22:45:08 -0400 Subject: [TUHS] Array index history In-Reply-To: <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> Message-ID: > > Arrays can be efficiently implemented no matter where the index starts. > Keep in mind that C was/is primarily a language to write OS's and other system level software. Hardware such as memory addresses, page tables, disk sectors, etc. are all indexed from zero for very good reasons. I would shudder to contemplate an implementation of the Unix V6 kernel in a hypothetical C-with-one-based-arrays language. From dave at horsfall.org Thu Jun 8 14:05:15 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Jun 2017 14:05:15 +1000 (EST) Subject: [TUHS] Array index history In-Reply-To: References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> Message-ID: On Wed, 7 Jun 2017, Robert Swierczek wrote: > Keep in mind that C was/is primarily a language to write OS's and other > system level software. Hardware such as memory addresses, page tables, > disk sectors, etc. are all indexed from zero for very good reasons. I > would shudder to contemplate an implementation of the Unix V6 kernel in > a hypothetical C-with-one-based-arrays language. Weren't the Burroughs mainframes implemented in Algol, likely with a 1-origin? Of course, I could be wrong (it was quite a few years ago since I touched a B-1700)... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From peter at rulingia.com Thu Jun 8 16:19:51 2017 From: peter at rulingia.com (Peter Jeremy) Date: Thu, 8 Jun 2017 16:19:51 +1000 Subject: [TUHS] Array index history In-Reply-To: References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> Message-ID: <20170608061951.GD83216@server.rulingia.com> On 2017-Jun-07 22:45:08 -0400, Robert Swierczek wrote: >Keep in mind that C was/is primarily a language to write OS's and >other system level software. Hardware such as memory addresses, page >tables, disk sectors, etc. are all indexed from zero for very good >reasons. I would shudder to contemplate an implementation of the Unix >V6 kernel in a hypothetical C-with-one-based-arrays language. Two counter-examples 1) CHS numbers sectors starting from 1, not 0. 2) Pr1meOS was written in Fortran. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From dave at horsfall.org Thu Jun 8 17:02:01 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 8 Jun 2017 17:02:01 +1000 (EST) Subject: [TUHS] Array index history In-Reply-To: <20170608061951.GD83216@server.rulingia.com> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> <20170608061951.GD83216@server.rulingia.com> Message-ID: On Thu, 8 Jun 2017, Peter Jeremy wrote: > Two counter-examples > 1) CHS numbers sectors starting from 1, not 0. Ah, those were the days, writing drivers for RK-11s etc... > 2) Pr1meOS was written in Fortran. Ironic, really, considering that "1" is not prime :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From michael at kjorling.se Thu Jun 8 17:54:38 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 8 Jun 2017 07:54:38 +0000 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: <86b6acb7-93ec-0dbd-b5a1-bd566e8c3cef@retro11.de> References: <86b6acb7-93ec-0dbd-b5a1-bd566e8c3cef@retro11.de> Message-ID: <20170608075438.GF7802@yeono.kjorling.se> On 7 Jun 2017 22:14 +0200, from w.f.j.mueller at retro11.de (Walter F.J. Mueller): > To Michael Kjörling remark >> The PC value in the panic report ("pc 161324") strikes me as high > and Johnny Billquist remark >> This is in kernel mode, and that is in the I/O page. > > 211bsd uses split I/D space and uses all 64 kB I space for code. > The top 8 kB are in fact the overlay area, and the crash happened > in overlay 4 (as indicated by ov 4). With a simple Note what follows in the sentence which you snipped: > ...but 161324 octal is 58068 decimal, so it's not excessively so, > and perhaps in line with what one might expect to see... -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From richard at inf.ed.ac.uk Thu Jun 8 19:16:52 2017 From: richard at inf.ed.ac.uk (Richard Tobin) Date: Thu, 8 Jun 2017 10:16:52 +0100 (BST) Subject: [TUHS] Array index history In-Reply-To: arnold@skeeve.com's message of Wed, 07 Jun 2017 07:20:43 -0600 Message-ID: <20170608091652.639C8130C058@macaroni.inf.ed.ac.uk> > Basically, until C came along, the standard practice was for indices > to start at 1. Certainly Fortran and Pascal did it that way. Mercury Autocode used 0. http://www.homepages.ed.ac.uk/jwp/history/mercury/manual/autocode/4.jpg -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From chneukirchen at gmail.com Thu Jun 8 21:28:28 2017 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Thu, 08 Jun 2017 13:28:28 +0200 Subject: [TUHS] Array index history In-Reply-To: <201706071402.v57E2dTs032508@freefriends.org> (arnold@skeeve.com's message of "Wed, 07 Jun 2017 08:02:39 -0600") References: <201706071320.v57DKhmJ026303@freefriends.org> <20170607135004.GB7802@yeono.kjorling.se> <201706071402.v57E2dTs032508@freefriends.org> Message-ID: <87o9tybtwj.fsf@gmail.com> arnold at skeeve.com writes: > Michael Kjörling wrote: > >> On the other hand, before C, both B and BCPL used zero-based indexing. >> So if we trace C's family tree, there is certainly precedence for >> zero-based indexing into arrays. > > Ah. OK. I never used either language. I get the impression that BCPL > wasn't used / known much in the US, but I could be wrong. I was exposed > to BASIC and FORTRAN (and computer programming) circa 1976 and to C > in 1980. Anything before then is before my time ... :-) It may be obvious, but awk(1) uses 1-indexing for arrays and string offsets, and shell arguments are indexed from 1 too (which may be reasonable given the special behavior of argv[0], but I think this resulted in rc(1) being 1-indexed for lists). pic(1) sensibly uses 1-indexing in the "Nth" notation. -- Christian Neukirchen http://chneukirchen.org From ches at cheswick.com Thu Jun 8 22:49:51 2017 From: ches at cheswick.com (William Cheswick) Date: Thu, 8 Jun 2017 08:49:51 -0400 Subject: [TUHS] Array index history In-Reply-To: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> Message-ID: <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> When he tests a microphone, Don Knuth says: “Testing zero, one, two.” > On 7Jun 2017, at 10:27 PM, Doug McIlroy wrote: > > Dijkstra, > too, often inveighed against 1-indexing, and opined that > zero was the true computer-science way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Thu Jun 8 22:56:44 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 8 Jun 2017 12:56:44 +0000 Subject: [TUHS] Array index history In-Reply-To: <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> Message-ID: <20170608125644.GG7802@yeono.kjorling.se> On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick): > When he tests a microphone, Don Knuth says: > > “Testing zero, one, two.” As opposed to Niklaus Wirth, who presumably would rather say: "Testing lower bound, lower bound plus one, lower bound plus two." -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From crossd at gmail.com Thu Jun 8 23:45:49 2017 From: crossd at gmail.com (Dan Cross) Date: Thu, 8 Jun 2017 09:45:49 -0400 Subject: [TUHS] Array index history In-Reply-To: <20170608125644.GG7802@yeono.kjorling.se> References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> <20170608125644.GG7802@yeono.kjorling.se> Message-ID: On Thu, Jun 8, 2017 at 8:56 AM, Michael Kjörling wrote: > On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick): > > When he tests a microphone, Don Knuth says: > > > > “Testing zero, one, two.” > > As opposed to Niklaus Wirth, who presumably would rather say: > > "Testing lower bound, lower bound plus one, lower bound plus two." "Testing: the set N, defined so that there are some elements 'b' and 'e' in N with known values taken from the integers and such that b less than or equal 'e' and every other element is both the natural successor of an element in N and less than or equal to 'e'." -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Thu Jun 8 23:49:49 2017 From: random832 at fastmail.com (Random832) Date: Thu, 08 Jun 2017 09:49:49 -0400 Subject: [TUHS] Array index history In-Reply-To: <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> Message-ID: <1496929789.1143160.1002957384.3AD574C4@webmail.messagingengine.com> On Wed, Jun 7, 2017, at 15:15, Arthur Krewat wrote: > On 6/7/2017 3:03 PM, Ron Natalie wrote: > >> Why go to the trouble of decrementing the index to retreive the first entry? > > What makes you think that you have to decrement the index. Don't get sucked up in the idiotic C implementation of an array. Arrays can be efficiently implemented no matter where the index starts. > > In the days when memory and clock cycles were costly, an extra decrement > or subtract was not something to be taken lightly :) You wouldn't need a decrement per access, because the base itself could still be stored as the address of the "0th" element (i.e. what would be the "-1th" in a 0-based system). It might add some extra complexity to the relocator, if it's not currently possible to have a reference outside the bounds of an object and/or with a negative offset, but statically linked programs (the only kind on V7 and earlier) did not do any runtime relocation. From ron at ronnatalie.com Thu Jun 8 23:53:44 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 8 Jun 2017 09:53:44 -0400 Subject: [TUHS] Array index history In-Reply-To: <20170608061951.GD83216@server.rulingia.com> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> <20170608061951.GD83216@server.rulingia.com> Message-ID: <01de01d2e05e$a57d84e0$f0788ea0$@ronnatalie.com> Original PR1MEOS was a weird beast. Not just Fortran, but FortranIV which is beyond the array index issues is far from a language I'd want to have to build a lot of low level contructs in. No structured aspects of it at all (indeed, this was the impetus for RATFOR, though I don't think Prime ever saw it). They didn't stay with Fortran long. They wrote their own PL/1 variant called PL/P a scheme also implemented at UNIVAC (PLUS) and IBM (PL/S). I would venture that C was the only systems implementation language that made the leap into a general purpose language. From krewat at kilonet.net Thu Jun 8 23:55:49 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 8 Jun 2017 09:55:49 -0400 Subject: [TUHS] Array index history In-Reply-To: <1496929789.1143160.1002957384.3AD574C4@webmail.messagingengine.com> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> <1496929789.1143160.1002957384.3AD574C4@webmail.messagingengine.com> Message-ID: On 6/8/2017 9:49 AM, Random832 wrote: > On Wed, Jun 7, 2017, at 15:15, Arthur Krewat wrote: >> In the days when memory and clock cycles were costly, an extra decrement >> or subtract was not something to be taken lightly :) > You wouldn't need a decrement per access, because the base itself could > still be stored as the address of the "0th" element (i.e. what would be > the "-1th" in a 0-based system). It might add some extra complexity to > the relocator, if it's not currently possible to have a reference > outside the bounds of an object and/or with a negative offset, but > statically linked programs (the only kind on V7 and earlier) did not do > any runtime relocation. > Shortly after making that statement, it occurred to me that the preprocessor or assembler could take care of that easily. Even better than worrying about whether arrays started at 0 or 1 in C would be to institute bounds checking in the first place :) But again would add lots of extra code that in the days of the origins of C was not something you wanted to add to the memory footprint. From ron at ronnatalie.com Thu Jun 8 23:57:55 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 8 Jun 2017 09:57:55 -0400 Subject: [TUHS] Array index history In-Reply-To: References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> <20170608125644.GG7802@yeono.kjorling.se> Message-ID: <01e301d2e05f$3b060190$b11204b0$@ronnatalie.com> My other favorite Wirth joke (I believe he coined himself) plays fun with the pronunciation of his name: You can call me by name… VEERTH or by value… WORTH. From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dan Cross Sent: Thursday, June 8, 2017 9:46 AM To: Michael Kjörling Cc: TUHS main list Subject: Re: [TUHS] Array index history On Thu, Jun 8, 2017 at 8:56 AM, Michael Kjörling wrote: On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick): > When he tests a microphone, Don Knuth says: > > “Testing zero, one, two.” As opposed to Niklaus Wirth, who presumably would rather say: "Testing lower bound, lower bound plus one, lower bound plus two." "Testing: the set N, defined so that there are some elements 'b' and 'e' in N with known values taken from the integers and such that b less than or equal 'e' and every other element is both the natural successor of an element in N and less than or equal to 'e'." -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag4ve.us at gmail.com Fri Jun 9 00:56:18 2017 From: ag4ve.us at gmail.com (shawn wilson) Date: Thu, 8 Jun 2017 10:56:18 -0400 Subject: [TUHS] Array index history In-Reply-To: <87o9tybtwj.fsf@gmail.com> References: <201706071320.v57DKhmJ026303@freefriends.org> <20170607135004.GB7802@yeono.kjorling.se> <201706071402.v57E2dTs032508@freefriends.org> <87o9tybtwj.fsf@gmail.com> Message-ID: On Jun 8, 2017 7:29 AM, "Christian Neukirchen" wrote: arnold at skeeve.com writes: > Michael Kjörling wrote: > >> On the other hand, before C, both B and BCPL used zero-based indexing. >> So if we trace C's family tree, there is certainly precedence for >> zero-based indexing into arrays. > > Ah. OK. I never used either language. I get the impression that BCPL > wasn't used / known much in the US, but I could be wrong. I was exposed > to BASIC and FORTRAN (and computer programming) circa 1976 and to C > in 1980. Anything before then is before my time ... :-) It may be obvious, but awk(1) uses 1-indexing for arrays and string offsets, and shell arguments are indexed from 1 too (which may be reasonable given the special behavior of argv[0], but I think this resulted in rc(1) being 1-indexed for lists). pic(1) sensibly uses 1-indexing in the "Nth" notation. I never thought of it like that wrt awk. However, I always thought of $0 as "self" in higher level OO languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Jun 9 01:04:39 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 9 Jun 2017 01:04:39 +1000 (EST) Subject: [TUHS] Array index history In-Reply-To: <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> Message-ID: Just to diverge from this thread a little, it probably isn't all that remarkable that programming languages tend to reflect the hardware for which they were designed. Thus, for example, we have the C construct: do { ... } while (--i); which translated right into the PDP-11's "SOB" instruction (and reminiscent of FORTRAN's insistence that DO loops are run at least once (there was a CACM article about that once; anyone have a pointer to it?)). And of course the afore-mentioned FORTRAN, which really reflects the underlying IBM 70x architecture (shudder). I know that Burroughs' iron ran ALGOL; I shudder to think of any box that runs native PERL... Speaking of Burroughs (which we weren't), their OS was MCP (Master Control Program) which we the great unwashed called Male Chauvinist Pig, no doubt to their distress :-) Any other examples of poor acronyms designed by ignorant marketoids? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From pechter at gmail.com Fri Jun 9 01:09:43 2017 From: pechter at gmail.com (William Pechter) Date: Thu, 8 Jun 2017 11:09:43 -0400 Subject: [TUHS] Array index history In-Reply-To: References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> Message-ID: DEC Professional Operating System POS. Great acronym there... -----Original Message---- Speaking of Burroughs (which we weren't), their OS was MCP (Master Control Program) which we the great unwashed called Male Chauvinist Pig, no doubt to their distress :-) Any other examples of poor acronyms designed by ignorant marketoids? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From usotsuki at buric.co Fri Jun 9 02:53:40 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 8 Jun 2017 12:53:40 -0400 (EDT) Subject: [TUHS] Array index history In-Reply-To: References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> Message-ID: On Fri, 9 Jun 2017, Dave Horsfall wrote: > Speaking of Burroughs (which we weren't), their OS was MCP (Master Control > Program) which we the great unwashed called Male Chauvinist Pig, no doubt > to their distress :-) Any other examples of poor acronyms designed by > ignorant marketoids? Apple had SOS. -uso. From david at kdbarto.org Fri Jun 9 04:20:24 2017 From: david at kdbarto.org (David) Date: Thu, 8 Jun 2017 11:20:24 -0700 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: <09918D02-9DA7-46B8-873E-A60489570400@kdbarto.org> Arnold gets it right on the Pascal indexing. In UCSD Pascal you could specify any array bounds you would like and the compiler would 0 base them for you by always doing a subtraction, or addition if your min was negative, of your min array index. So a little run time cost for non-zero based arrays. I’m not sure how other Pascal compilers did this. I find it interesting that there are now a slew of testing programs (Valgrind, Address Sanitizer, Purify, etc) that will add the ‘missing’ array bounds checking for C. David > On Jun 7, 2017, at 10:01 AM, tuhs-request at minnie.tuhs.org wrote: > > Date: Wed, 07 Jun 2017 07:20:43 -0600 > From: arnold at skeeve.com > To: tuhs at tuhs.org, ag4ve.us at gmail.com > Subject: Re: [TUHS] Array index history > Message-ID: <201706071320.v57DKhmJ026303 at freefriends.org> > Content-Type: text/plain; charset=us-ascii > > Pascal (IIRC) allowed you to specify upper and lower bounds, something > like > > foo : array[5..10] of integer; > > with runtime bounds checking on array accesses. (I could be wrong --- > it's been a LLLLOOONNNGGG time.) > > HTH, > > Arnold From tfb at tfeb.org Fri Jun 9 04:41:55 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Thu, 8 Jun 2017 19:41:55 +0100 Subject: [TUHS] Array index history In-Reply-To: <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> References: <23afd785-e260-75ca-5c46-77c62fbcf3cd@kilonet.net> <016301d2dfc0$b098e250$11caa6f0$@ronnatalie.com> <57dce8ab-153d-89ce-91d6-07d9f01f7d6b@kilonet.net> Message-ID: > On 7 Jun 2017, at 20:15, Arthur Krewat wrote: > > In the days when memory and clock cycles were costly, an extra decrement or subtract was not something to be taken lightly :) Indeed they weren't, and that's how we know that 1-based indexing doesn't require any overhead given a reasonably good compiler. If you'd gone to people writing big CFD simulations in 1975 and told them that by using a version of FORTRAN which had 0-based arrays they could save any significant runtime at all then they would have changed to it without a thought. But they didn't. From ron at ronnatalie.com Fri Jun 9 04:55:03 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 8 Jun 2017 14:55:03 -0400 Subject: [TUHS] Array index history In-Reply-To: <09918D02-9DA7-46B8-873E-A60489570400@kdbarto.org> References: <09918D02-9DA7-46B8-873E-A60489570400@kdbarto.org> Message-ID: <024101d2e088$bd71eda0$3855c8e0$@ronnatalie.com> = > I find it interesting that there are now a slew of testing programs (Valgrind, Address Sanitizer, Purify, etc) that will add the ‘missing’ > array bounds checking for C. And nothing prevents a C compiler from doing bounds checking, it's just not obliged to. There are C compilers that will allow you to enable such checks for debugging purposes. From lm at mcvoy.com Fri Jun 9 06:17:05 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 8 Jun 2017 13:17:05 -0700 Subject: [TUHS] Array index history In-Reply-To: References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> Message-ID: <20170608201705.GA24069@mcvoy.com> > I know that Burroughs' iron ran ALGOL; I shudder to think of any box that > runs native PERL... Huh? If I couldn't have C on the iron I'd be ecstatic with perl 4 (I'm old, never warmed up to perl 5). In fact, while I was at Sun I proposed rewriting a pile of /usr/bin in perl 4 just because it would be more maintainable. I did walk that back at some point but I love me some perl. I've moved on because I created my own C/perl combo language and that's what I do most of my programming in these days. http://mcvoy.com/lm/photos.l is an example. I'm in Europe right now, you can see the results of photos.l here (warning ~8MB of thumbnails): http://mcvoy.com/lm/europe I'm very fond of that language, it's like a scripting version of C, has structs, but has all the fun stuff from perl. Docs here: http://www.mcvoy.com/lm/L/L.html From bqt at update.uu.se Fri Jun 9 08:28:54 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 9 Jun 2017 00:28:54 +0200 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: <1084a817-e0ff-86b2-06bb-b5738dd4b2ce@update.uu.se> On 2017-06-08 22:17, Dave Horsfall wrote: > > Just to diverge from this thread a little, it probably isn't all that > remarkable that programming languages tend to reflect the hardware for > which they were designed. > > Thus, for example, we have the C construct: > > do { ... } while (--i); > > which translated right into the PDP-11's "SOB" instruction (and > reminiscent of FORTRAN's insistence that DO loops are run at least once > (there was a CACM article about that once; anyone have a pointer to it?)). > > And of course the afore-mentioned FORTRAN, which really reflects the > underlying IBM 70x architecture (shudder). FORTRAN stopped running the loops at least once already with FORTRAN 77. The last who insisted on running loops at least once was FORTRAN IV. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at update.uu.se Fri Jun 9 08:29:13 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 9 Jun 2017 00:29:13 +0200 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: References: Message-ID: <078af6e5-fa47-c66f-1d30-b4265277419a@update.uu.se> On 2017-06-07 22:14, "Walter F.J. Mueller" wrote: > Hi, > > a few remarks on the feedback on the kernel panic after a 'here document' in tcsh. > > To Michael Kjörling question: > > I'm curious whether the same thing happens if you try that in some > > other shell? (Not sure how widely here documents were supported back > > then, but I'm asking anyway.) > And Johnny Billquist remark > > Not sure if any of the other shells have this. > > 'here documents' are available and work fine in sh and csh. > And are in fact used, examples Ah. Thanks. Too lazy to check. > To Michael Kjörling remark > > The PC value in the panic report ("pc 161324") strikes me as high > and Johnny Billquist remark > > This is in kernel mode, and that is in the I/O page. > > 211bsd uses split I/D space and uses all 64 kB I space for code. D'oh! Color me stupid. I should have thought of that. > The top 8 kB are in fact the overlay area, and the crash happened > in overlay 4 (as indicated by ov 4). With a simple > > nm /unix | sort | grep " 4" > > one gets > > 161254 t ~psignal 4 > 162302 t ~issignal 4 > > so the crash is just 050 bytes after the entry point of psignal. So the > PC address is fine and not the problem. For psignal look at > > http://www.retro11.de/ouxr/211bsd/usr/src/sys/sys/kern_sig.c.html#s:_psignal > > the crash must be one of the first lines. psignal is an internal kernel > function, called from > > http://www.retro11.de/ouxr/211bsd/usr/src/sys/sys/kern_sig.c.html#xref:s:_psignal > > and has nothing to do with the libc function psignal > > http://www.retro11.de/ouxr/211bsd/usr/man/cat3/psignal.0.html > http://www.retro11.de/ouxr/211bsd/usr/src/lib/libc/gen/psignal.c.html The libc function would be in user mode, so that one was pretty clear. Ok. Digging through this a little for real then. psignal gets called with a signal from the trap handler. The actual signal is weird. It would appear to be 0160750, which would be -7704 if I'm counting right. That does not make sense as a signal. The psignal code pulls a value based on the signal number, which is the line: prop = sigprop[sig]; which uses the signal number as an index. With a random, weird signal number, this access wherever that might end up. Which is when you get the crash. On my system, sigprop is at address 0012172, which, with a signal of -7704 ends up at address 0173142, which by (un)luck happens to be in the middle of the diagnostics bootstrap rom space. So I don't get a Unibus timeout error, while you do. Probably because sigprop is at a slightly different address in your kernel. So, the real question is how trap can be calling psignal with such a broken signal number. I might dig further down that question another day. But unless you already got this far, I might have saved you a few minutes of digging. I did start looking into the trap code, which is in pdp/trap.c, but this is not entirely straight forward. It goes through a bunch of things trying to decide what signal to send, before actually calling psignal. > To Johnny Billquist remark > > Could you (Walter) try the latest version of 2.11BSD and see if you > > still get that crash? > > very interesting that you see a core dump of tcsh rather a kernel panic. Indeed. > Whatever tcsh does, it should not lead to a kernel panic, and if it does, > it is primarily a bug of the kernel. It looks like there are two issues, > one in tcsh, and one in the kernel. I've a hunch were this might come from, > but that will take a weekend or two to check on. Agree that the kernel should not crash on this. Also, tcsh should not really crash either, but it's a separate issue, even though one might have triggered the other here. But yes, there are two bugs in here. If you can recreate the kernel crash on the latest version, that would be good. But it smells like trap.c have some path where it does not even set what signal to deliver, and then calls psignal with whatever the variable i got at the function start. Which would be some random stuff on the stack. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt at update.uu.se Fri Jun 9 08:29:29 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 9 Jun 2017 00:29:29 +0200 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: On 2017-06-07 19:01, "Ron Natalie" wrote: > The original FORTRAN and BASIC arrays started indexing at one because everybody other than computer scientists start counting at 1. FORTRAN, yes. BASIC (which dialect might we be talking about?) normally actually start with 0. However, BASIC is weird, in that the DIM statement is actually specifying the highest usable index, and not the size of the array. Thus: DIM X(10) means you get an array with 11 elements. So, people who wanted to use array starting at 1 would still be happy, and if you wanted to start at 0, that also worked. You might unintentionally have a bit of wasted memory, though. > These languages were for scientists and the beginner, so you wanted to make things compatible with their normal concepts. True. > PASCAL on the other hand required you to give the minimum and maximum index for the array. In a way, PASCAL makes the most sense. You still what range you want, and you get that. Anything works, and it's up to you. That said, PASCAL could get a bit ugly when passing arrays as arguments to functions because of this. > Of course, C’s half-assaed implementation of arrays kind of depends on zero-indexing to work. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From ron at ronnatalie.com Fri Jun 9 09:16:48 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 8 Jun 2017 19:16:48 -0400 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> > FORTRAN, yes. BASIC (which dialect might we be talking about?) normally actually start with 0. However, BASIC is weird, in that the DIM statement is actually specifying the highest usable index, and not the size of the array. Eh? Not in any BASIC I ever used. They all started at 1. Can't vouch for the later Microsoft "visual" variants but the original 1970's era BASIC started with 1. DIM X(10) gave you ten elements from 1...10 From usotsuki at buric.co Fri Jun 9 09:41:11 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 8 Jun 2017 19:41:11 -0400 (EDT) Subject: [TUHS] Array index history In-Reply-To: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> References: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> Message-ID: On Thu, 8 Jun 2017, Ron Natalie wrote: > >> FORTRAN, yes. BASIC (which dialect might we be talking about?) normally > actually start with 0. However, BASIC is weird, in that the DIM statement is > actually specifying the highest usable index, and not the size of the array. > > Eh? Not in any BASIC I ever used. They all started at 1. Can't vouch > for the later Microsoft "visual" variants but the original 1970's era BASIC > started with 1. > DIM X(10) gave you ten elements from 1...10 All M$ dialects that I am aware of start at 0 by default. Later ones have OPTION BASE to change this or let you do DIM X(5 TO 7) if you want. -uso. From grog at lemis.com Fri Jun 9 10:03:08 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Fri, 9 Jun 2017 10:03:08 +1000 Subject: [TUHS] Array index history In-Reply-To: References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> Message-ID: <20170609000308.GB77283@eureka.lemis.com> On Friday, 9 June 2017 at 1:04:39 +1000, Dave Horsfall wrote: > > And of course the afore-mentioned FORTRAN, which really reflects the > underlying IBM 70x architecture (shudder). I had promised myself that I wouldn't get involved in this thread, but I had to step in here. Yes, the IBM 704 had the CAS instruction (Compare Accumulator with Storage), a three-way skip instruction that easily implemented the FORTRAN Arithmetic IF. But the "index" registers were correctly called decrement registers: their content was subtracted from the base address. I assume that this was because the 704 was a ones-complement machine whose basic arithmetic operation was subtraction, so this was cheaper than adding the registers to the base address. To implement indexing with the base 704 hardware, FORTRAN would have had to have an upper bound of -0 (remember that number?). Still, there were three decrement registers, and the original FORTRAN was limited to three dimensions, evidently as a result. > Speaking of Burroughs (which we weren't), their OS was MCP (Master > Control Program) which we the great unwashed called Male Chauvinist > Pig, no doubt to their distress :-) This name (the original one) cropped up again in the 1982 film "Tron" (http://www.imdb.com/title/tt0084827/). It was singularly inappropriate. Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From bqt at softjar.se Fri Jun 9 10:21:05 2017 From: bqt at softjar.se (Johnny Billquist) Date: Fri, 09 Jun 2017 02:21:05 +0200 Subject: [TUHS] Array index history In-Reply-To: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> References: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> Message-ID: <2F555C00-3202-4844-B0E8-862D016C47CF@softjar.se> All variants of BASIC by DEC does this. A few others I've tried also do. But since BASIC was not standardized for the longest time, it's hard to claim that BASIC really was one way or another. I have definitely not tried every dialect that has existed. Johnny Ron Natalie skrev: (9 juni 2017 01:16:48 CEST) > >> FORTRAN, yes. BASIC (which dialect might we be talking about?) >normally >actually start with 0. However, BASIC is weird, in that the DIM >statement is >actually specifying the highest usable index, and not the size of the >array. > >Eh? Not in any BASIC I ever used. They all started at 1. Can't >vouch >for the later Microsoft "visual" variants but the original 1970's era >BASIC >started with 1. >DIM X(10) gave you ten elements from 1...10 -- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at dunnington.plus.com Fri Jun 9 10:25:04 2017 From: pete at dunnington.plus.com (Pete Turnbull) Date: Fri, 9 Jun 2017 01:25:04 +0100 Subject: [TUHS] Array index history In-Reply-To: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> References: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> Message-ID: On 09/06/2017 00:16, Ron Natalie wrote: > >> FORTRAN, yes. BASIC (which dialect might we be talking about?) normally > actually start with 0. However, BASIC is weird, in that the DIM statement is > actually specifying the highest usable index, and not the size of the array. > > Eh? Not in any BASIC I ever used. They all started at 1. Can't vouch > for the later Microsoft "visual" variants but the original 1970's era BASIC > started with 1. > DIM X(10) gave you ten elements from 1...10 Well, my experience matches Johnny's. I used many derivatives of MicroSoft BASIC - PET, Apple INTBASIC, Applesoft, Exidy Sorcerer, and others - and they all start at 0. AFAIR HP BASIC did so as well. The original 1960s Dartmouth BASIC (for which I have a copy of the manual) also started at 0 (cf. page 38); indeed if you didn't explicitly DIM an array, you got eleven elements indexed 0...10. -- Pete Pete Turnbull From toby at telegraphics.com.au Fri Jun 9 11:19:16 2017 From: toby at telegraphics.com.au (Toby Thain) Date: Thu, 8 Jun 2017 21:19:16 -0400 Subject: [TUHS] Array index history In-Reply-To: References: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> Message-ID: <1b557724-cbd5-8602-3b75-5e68df9e7a3f@telegraphics.com.au> On 2017-06-08 8:25 PM, Pete Turnbull wrote: > On 09/06/2017 00:16, Ron Natalie wrote: >> >>> FORTRAN, yes. BASIC (which dialect might we be talking about?) normally >> actually start with 0. However, BASIC is weird, in that the DIM >> statement is >> actually specifying the highest usable index, and not the size of the >> array. >> >> Eh? Not in any BASIC I ever used. They all started at 1. Can't vouch >> for the later Microsoft "visual" variants but the original 1970's era >> BASIC >> started with 1. >> DIM X(10) gave you ten elements from 1...10 > > Well, my experience matches Johnny's. I used many derivatives of > MicroSoft BASIC - PET, Apple INTBASIC, Applesoft, Exidy Sorcerer, and > others - and they all start at 0. AFAIR HP BASIC did so as well. The > original 1960s Dartmouth BASIC (for which I have a copy of the manual) > also started at 0 (cf. page 38); indeed if you didn't explicitly DIM an > array, you got eleven elements indexed 0...10. > I wrote a lot of BBC BASIC. DIM(9) allocates ten elements, 0..9, according to this: http://www.riscos.com/support/developers/bbcbasic/part2/arrays.html --Toby From pete at dunnington.plus.com Fri Jun 9 12:14:20 2017 From: pete at dunnington.plus.com (Pete Turnbull) Date: Fri, 9 Jun 2017 03:14:20 +0100 Subject: [TUHS] Array index history In-Reply-To: <1b557724-cbd5-8602-3b75-5e68df9e7a3f@telegraphics.com.au> References: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> <1b557724-cbd5-8602-3b75-5e68df9e7a3f@telegraphics.com.au> Message-ID: <4031f861-8f47-0b1d-f635-c39ebc4b54e0@dunnington.plus.com> On 09/06/2017 02:19, Toby Thain wrote: > I wrote a lot of BBC BASIC. DIM(9) allocates ten elements, 0..9, Yes, all versions (of which there are at least nine, going back to 1981), and so too does its predecessor, Atom BASIC. Indexing from zero was the norm in 1970s/1980s BASICs. -- Pete Pete Turnbull From random832 at fastmail.com Sat Jun 10 01:12:07 2017 From: random832 at fastmail.com (Random832) Date: Fri, 09 Jun 2017 11:12:07 -0400 Subject: [TUHS] Array index history In-Reply-To: References: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> Message-ID: <1497021127.379252.1004231632.6AEF6E27@webmail.messagingengine.com> On Thu, Jun 8, 2017, at 19:41, Steve Nickolas wrote: > On Thu, 8 Jun 2017, Ron Natalie wrote: > > DIM X(10) gave you ten elements from 1...10 > > All M$ dialects that I am aware of start at 0 by default. In fact, they give you eleven elements from 0 to 10, which means that code which *uses* 1..10 is compatible but wastes some space. From ron at ronnatalie.com Sat Jun 10 02:30:11 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 9 Jun 2017 12:30:11 -0400 Subject: [TUHS] Array index history In-Reply-To: <1497021127.379252.1004231632.6AEF6E27@webmail.messagingengine.com> References: <026801d2e0ad$4e13cc10$ea3b6430$@ronnatalie.com> <1497021127.379252.1004231632.6AEF6E27@webmail.messagingengine.com> Message-ID: <031201d2e13d$abd3ba00$037b2e00$@ronnatalie.com> I stand corrected. I pulled up the original typewritten Dartmouth BASIC manual and indeed the indices start at zero (though many coding examples don't write the zeroth element). By default arrays were 11 elements long. You could change that with the DIM statement. Yes, the value given to DIM is the highest index making a DIM A(20) defining a 21 element array. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Random832 Sent: Friday, June 9, 2017 11:12 AM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Array index history On Thu, Jun 8, 2017, at 19:41, Steve Nickolas wrote: > On Thu, 8 Jun 2017, Ron Natalie wrote: > > DIM X(10) gave you ten elements from 1...10 > > All M$ dialects that I am aware of start at 0 by default. In fact, they give you eleven elements from 0 to 10, which means that code which *uses* 1..10 is compatible but wastes some space. From scj at yaccman.com Sat Jun 10 07:21:57 2017 From: scj at yaccman.com (Steve Johnson) Date: Fri, 09 Jun 2017 14:21:57 -0700 Subject: [TUHS] Array index history In-Reply-To: <09918D02-9DA7-46B8-873E-A60489570400@kdbarto.org> Message-ID: I'd like to comment on the technical difficulty of array bounds checking.   First of all, there are two kinds.   The simple kind computes the index and simply checks that the address is within the array.  This can be done fairly easily -- create a pointer to the end of the array, and test against it (and with a bit more work, "pre-test" loops so you don't need to test each element).  If you ignore possible negative subscripts, it's even easier.  And it catches a lot of the ugliest bugs.  The harder version checks the range of each index in a multidimensional array separately.  This is quite a bit more work, although it too can be optimized significantly with enough work.  And if C didn't conflate arrays and pointers, I suspect this would have been added to C long ago. But C does conflate arrays and pointers.   When an array is passed to a function, all that is passed is the location.  There is no clue what the size is.  To even pass in the "end of array" pointer gets expensive, since more registers need to be saved and loaded on each call.  Correct negative subscripts are not unheard of when passing part of an array into a functions.  And utilities like malloc get more complicated as well, and for some of malloc's other uses (e.g., in class object creation) the checks would be inappropriate.  And finally, because pointers are extensively used in data structures, pointer conventions are often used when using arrays (e.g., passing in NULL when an array argument is not present or needed). There is yet another problem.  If array size or shape information were somehow passed with arrays, it would be unkind for the language to give the programmer no way to find out what the size(s) are.  This desire ultimately leads to a rich calling convention like that of MATLAB where you can have multiple function outputs, determine how many inputs are present, and inputs will disclose their size and shape on request.  Good to program in, but function calls are quite a bit more expensive. Realizing that most system code at the time of C's invention was still written in assembler and PDP-11's were almost too small in memory to do anything interesting (my laptop currently has roughly 243,000 times the memory space of a PDP-11!), C's conventions provided a big improvement in code correctness with a small cost when compared to assembler... Steve ----- Original Message ----- From: david at kdbarto.org To: Cc: Sent:Thu, 8 Jun 2017 11:20:24 -0700 Subject:Re: [TUHS] Array index history Arnold gets it right on the Pascal indexing. In UCSD Pascal you could specify any array bounds you would like and the compiler would 0 base them for you by always doing a subtraction, or addition if your min was negative, of your min array index. So a little run time cost for non-zero based arrays. I’m not sure how other Pascal compilers did this. I find it interesting that there are now a slew of testing programs (Valgrind, Address Sanitizer, Purify, etc) that will add the ‘missing’ array bounds checking for C. David > On Jun 7, 2017, at 10:01 AM, tuhs-request at minnie.tuhs.org wrote: > > Date: Wed, 07 Jun 2017 07:20:43 -0600 > From: arnold at skeeve.com > To: tuhs at tuhs.org, ag4ve.us at gmail.com > Subject: Re: [TUHS] Array index history > Message-ID: <201706071320.v57DKhmJ026303 at freefriends.org> > Content-Type: text/plain; charset=us-ascii > > Pascal (IIRC) allowed you to specify upper and lower bounds, something > like > > foo : array[5..10] of integer; > > with runtime bounds checking on array accesses. (I could be wrong --- > it's been a LLLLOOONNNGGG time.) > > HTH, > > Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Sat Jun 10 07:52:16 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 9 Jun 2017 17:52:16 -0400 Subject: [TUHS] Array index history In-Reply-To: References: Message-ID: <70047882-7de3-162d-c4b5-6b6f0b4c82fa@kilonet.net> On 6/9/2017 5:21 PM, Steve Johnson wrote: > C's conventions provided a big improvement in code correctness with a > small cost when compared to assembler.. Being an assembler snob for a number of years when I first started programming, having started with MACRO-10 on a PDP-10 in high school, I was reluctant to consider C as an alternative. At one point early on, I decided I would see what the difference was in actual performance. So, on an IBM-AT, I wrote two programs. Both did a wire-frame rotation of a 3D cube, rotating around both the X and Y axis. They both used my own graphics library written in assembler that used the basic BIOS graphics calls to draw lines in 3D. One program was written in straight Intel 80286 assembler. The other, in C, C86 from Computer Innovations, Inc. The straight assembler version, I wrote using double-word integers. One word for everything above the decimal point, one word for everything below the decimal point. Now, because of the loss of precision, and that I defined the matrices for rotation as static integers, after a few hundred iterations, the cube would start to deform but it was a proof of concept. The C version, I used real sin(), cos(), but - the interesting part is that I didn't have a floating point coprocessor - so the floating point was emulated in the supplied math library. The assembler version ran at a ratio of 3:4 compared to the C version.Meaning if the assembler version did X rotations in 3 minutes, the C version did it in 4 minutes. BUT - the C version cube didn't deform over time, because the accuracy was intact. After that, I gave up on assembler except where critical. C as a concept did what I needed it to do ;) On topic for this conversation is the fact that arrays in C are basically a perfect mapping to assembler. if you moved from assembler to C like I did, there was no concern over "arrays should start at 1". It was just intuitive anyway. On the other hand, if you went from some other language to C, well, I can understand the alien-ness. art k. From w.f.j.mueller at retro11.de Sat Jun 10 22:58:43 2017 From: w.f.j.mueller at retro11.de (Walter F.J. Mueller) Date: Sat, 10 Jun 2017 14:58:43 +0200 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh Message-ID: Hi, the kernel panic after tcsh here documents is understood. And fixed, at least on my system. The essential hint was Johnny's observation that on his system he gets an "Illegal instruction - core dumped" and no kernel panic. I'm using a self-build PDP 11/70 on an FPGA, see https://github.com/wfjm/w11/ https://wfjm.github.io/home/w11/ which doesn't have a floating point unit. Therefore the kernel is build with floating point emulation, thus with FPSIM YES # floating point simulator In a kernel with FPSIM activated the trap handler trap(), see http://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/trap.c.html calls for each user mode illegal instruction trap fpsim(). In case it was a floating point instruction fpsim() emulates it, returns 0, and trap() simply returns. If not, fpsim() returns the abort signal type, and trap() calls psignal() with this signal type, which in general will terminate the offending process. The kernel panic is due to a coding error in mch_fpsim.s. Look in http://www.retro11.de/ouxr/211bsd/usr/src/sys/pdp/mch_fpsim.s.html the code after label badins: badins: / Illegal Instruction mov $SIGILL.,r0 br 2b The constant SIGILL is defined in assym.h as #define SIGILL 4. Thus after substitution the mov instruction is mov $4..,r0 with *two dots* !!! The 'as' assembler generates from this mov #160750,r0 So r0 will contain a invalid signal number, which is returned by fpsim() to trap(). This signal number is passed to psignal(), which starts with mask = sigmask(sig); prop = sigprop[sig]; The access to sigprop[sig] results into an address in IO space, causes an UNIBUS timeout, and in consequence the kernel panic. After fixing the "$SIGILL." to "$SIGILL" (removing the extraneous '.') and three similar cases the kernel doesn't panic anymore, tcsh crashed with an illegal instruction trap. Remains the question why tcsh runs onto an illegal instruction. Getting now a tcsh core dump adb gives the answer adb tcsh tcsh.core $c 0172774: _rscan(0176024,0174434) from ~heredoc+0246 0176040: _heredoc(067676) from ~execute+0234 0176126: _execute(067040,01512,0,0) from ~execute+03410 0176222: _execute(066754,01512,0,0) from ~process+01224 0176274: _process(01) from ~main+06030 0177414: _main() from start+0104 heredoc(), which is located in OV1, calls rscan(), which is in OV6 with rscan(Dv, Dtestq); where Dtestq is a function pointer to Dtestq(), which is as heredoc() in OV1. rscan(), which has the signature rscan(t, f) register Char **t; void (*f) (); uses 'f' in the statement (*f) (*p++); The problem is that - heredoc() and Dtestq() are in OV1 - that's why in the end ~Dtestq is used a function pointer, like for all overlay internal function invocations - rscan() is in OV6, when it's called, overlay is switched OV1 -> OV6 - this invalidates the function pointer, which points to some random code location, which happens to hold '000045', causing a trap. It is clear that in this context _Dtestq, the forwarder in the base, must be used and not ~Dtestq, the entry point in the overlay. The generated code for 'rscan(Dv, Dtestq)' is ~heredoc+0230: mov $0174434,(sp) # arg Dtestq: uses ~Dtestq ~heredoc+0234: mov r5,-(sp) ~heredoc+0236: add $0177764,(sp) # arg Dv ~heredoc+0242: jsr pc,*$_rscan Since rscan() is very small and only used by heredoc() I simply moved the code of rscan() from sh.glob.c (OV6) to sh.dol.c where also heredoc() and Dtestq() is defined. After that tcsh works fine with here documents ./tcsh cat >x.x < > From: "Walter F.J. Mueller" > the kernel panic after tcsh here documents is understood. Very nice detective work! > The kernel panic is due to a coding error in mch_fpsim.s. ... After > fixing the "$SIGILL." ... and three similar cases I'm fairly amazed that apparently nobody has run across one of these 4 before! (Or, at least, not bothered to report it.) I wonder how long that bug has been in the code? Noel From cym224 at gmail.com Sun Jun 11 07:08:07 2017 From: cym224 at gmail.com (Nemo) Date: Sat, 10 Jun 2017 17:08:07 -0400 Subject: [TUHS] Array index history In-Reply-To: <20170608125644.GG7802@yeono.kjorling.se> References: <201706080227.v582R5D9056395@tahoe.cs.Dartmouth.EDU> <40F0B6B0-73C3-48CD-B75F-84CA6095433B@cheswick.com> <20170608125644.GG7802@yeono.kjorling.se> Message-ID: On 08/06/2017, Michael Kjörling wrote: > On 8 Jun 2017 08:49 -0400, from ches at cheswick.com (William Cheswick): >> When he tests a microphone, Don Knuth says: >> >> “Testing zero, one, two.” > > As opposed to Niklaus Wirth, who presumably would rather say: > > "Testing lower bound, lower bound plus one, lower bound plus two." In his latest language Oberon, all arrays start at zero. N. From bqt at update.uu.se Sun Jun 11 20:25:24 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Sun, 11 Jun 2017 12:25:24 +0200 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: References: Message-ID: On 2017-06-11 04:00, "Walter F.J. Mueller" wrote: > Hi, > > the kernel panic after tcsh here documents is understood. > And fixed, at least on my system. Nice work. Looking forward to patch #250. And to respond to Noels remark about this being around for a long time without reports - since this is in FPSIM, and I believe the notes for 2.11BSD even says that this is an untested piece of code, which are not even know if it works or not, it's not something that have been used for ages. I'm in a way surprised it even worked at all. I think I've seen somewhere that it was last tested around 2.9BSD, and have not been officially tested since. > The essential hint was Johnny's observation that on his system he gets > an "Illegal instruction - core dumped" and no kernel panic. Well, had I had FPP simulated, I would maybe not have gotten a kernel panic anyway. It would all depend on where the address ended up. With my current build, the kernel would have been able to read the address, since it pointed into the boot diagnostics rom. So it's a dicey error at best. But the tcsh error was very good that you also figured out. And I guess it means we now have a known working FPSIM. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From clemc at ccc.com Tue Jun 13 01:26:31 2017 From: clemc at ccc.com (Clem Cole) Date: Mon, 12 Jun 2017 11:26:31 -0400 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh In-Reply-To: <20170610142432.8CA3A18C0E4@mercury.lcs.mit.edu> References: <20170610142432.8CA3A18C0E4@mercury.lcs.mit.edu> Message-ID: Probably says that that once that most people that ran UNIX purchased the FP option and did not run the simulated FP and those that did clearly didn't use tcsh ;-) Fred Brook's bug's curves really are amazing but are so true. Some really major bugs just take years to be discovered because no one ever looked and when you do. It can be like this one -- 'wow!' Clem On Sat, Jun 10, 2017 at 10:24 AM, Noel Chiappa wrote: > > From: "Walter F.J. Mueller" > > > the kernel panic after tcsh here documents is understood. > > Very nice detective work! > > > The kernel panic is due to a coding error in mch_fpsim.s. ... After > > fixing the "$SIGILL." ... and three similar cases > > I'm fairly amazed that apparently nobody has run across one of these 4 > before! > (Or, at least, not bothered to report it.) > > I wonder how long that bug has been in the code? > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From camille.paloque-berges at lecnam.net Sat Jun 17 06:21:31 2017 From: camille.paloque-berges at lecnam.net (Paloque-berges Camille) Date: Fri, 16 Jun 2017 22:21:31 +0200 Subject: [TUHS] International conference: "Unix in Europe : between innovation, diffusion and heritage" In-Reply-To: References: Message-ID: <9ff57d45-7b85-f2d4-5c13-d65b68e433c2@lecnam.net> Dear THUS list, I am a recent lurker on this list, also a history and communication scholar looking at pieces of Unix history for my research. I hope it is okay if I share with you the news of a historical conference on Unix that we are organizing in France next Fall with fellow humanities scholars and computer scientists and engineers involved in the history and heritage of computing and computers. You are of course welcomed, even encouraged, to submit a proposal. It will be a pleasure to meet you at this conference in any case. Best, Camille Paloque-Berges *** Please find enclosed the CFP for the *international conference**"Unix in Europe: between innovation, diffusion and heritage"* that will take place in Cnam (Paris, France), October, 19th, 2017. A one-page abstract (maximum 500 words) with a short biography is expected for June 30th 2017. The Cfp is also available at : . Best regards, The organization comitee : Isabelle Astic, Raphaël Fournier-S'niehotta, Pierre-Eric Mounier-Kuhn, Camille Paloque-Berges, Loïc Petitgirard ------------------------------------------------------------ *Call for contributions* *International symposium * *Unix in Europe: between innovation, diffusion and heritage* */Conservatoire National des Arts et Métiers, Paris, France – October 19 2017/* ** Communications and discussions will be held in French or English. * * *Rationale* * * **The Unix system was born in the 1970s at the crossroads between two interacting worlds: industry (the Bell Labs at AT&T) and academia (the University of Berkeley computer science network). Its fast adoption throughout computer research and engineering networks across the world signaled the future success of the new system, fostering software experiments within its open, multi-user and multi-tasking system running on mini-computers – and later compatible with a larger part of computer hardware. In the European context, how was this American innovation propagated, adopted and adapted? Why was Unix of so much interest in this context, then and now? A solid culture of Unix users might also explain this success, as well as subsequent processes of appropriation and inheritance, due to the long and complex history of Unix versioning. The memory of Unix users is vivid indeed, fed by early accounts within the computer world (Salus, 1994) as well as preservation initiatives (Toomey, 2010). Moreover, the Unix system is a crucial reference in the history of computing, in particular in the field of free and open source software (Kelty, 2008), computer networks (Paloque-Berges, 2017), as well as in programming language philosophy (Mélès, 2013). In order to explore the variety of these interrogations, this symposium encourages contributions from historians as well as philosophers, social science researchers, and heritage professionals interested in the history of computer open systems and software with a focus on Unix or who have a wider perspective. It will also welcome protagonists and witnesses of Unix culture and carriers of its memory. We wish to discuss and shed light on several aspects of the development of Unix in Europe (including in comparison or relation with the rest of the world) along three main lines: historical and sociological, philosophical and epistemological, and heritage- and preservation-oriented. *1/ Historical and sociological perspectives* * * Historically, the Unix system is linked to the promotion and development in research on open systems and computer networks. How does this fit in the context of industrial, scientific and technological policies defined at the national and European level? The history of Unix thus reaches at least three levels of interrogations: 1/ the forms, places and practices of innovation around Unix in R&D labs and computing centers in companies, schools and universities; 2/ planning, promoting and negotiating open systems (norms and standards) from the perspective of science and/or politics; 3/ international geopolitical relations, whether economical or geopolitical and even geostrategic (for example between Unix users, with users of other computer equipment or other hardware and software companies, the role of embargos in the shipping of mini-computers, of code, and military uses of Unix). In parallel, how has the world of computer research welcomed, encouraged, negotiated and propagated uses and innovations related to Unix systems? This begs the question of how Unix-related research and development was legitimized - or played a part in the legitimization of computer science experimentalism in the scientific field and beyond. We would also like to highlight practices of resistance, the failure to acknowledge, ignorance of or even the limits of the Unix system, its software tools and hardware environment (beginning with the famous PDP and Vax machines from Digital Equipment where the first Unix versions were implemented). With a focus on occupational computer uses, we call for analysis which aims to explore and clarify: - the role of developers, users, and user associations – from the point of view of pioneers as well as helpers, maintainers and other witnesses of the implementation of Unix; - the context, process, and people who determined its propagation, appropriation, and development over time; - the meaning of concepts of Unix philosophy and ethics such as “openness” and “autonomy”, from a social, political or economic point of view. *2. Philosophical and epistemological perspectives* We will foster research and reflection at the crossroad of the theoretical foundations of computer systems and engineering pragmatism, between the philosophy of computer systems and Unixian practices. Protagonists in the conception and diffusion of Unix often claim to have a ‘Unix philosophy’ . But beyond statement of principle, what was the real influence of this idea on the technical choices underlying the system’s developments? What are the ethical, moral, and philosophical motivations – alongside the social, political or economic dimensions discussed earlier – underpinning the adoption of Unix or pretending to extend it (for instance in relation to the notions of sharing, modularity or freedom)? How is the idea of ‘openness’ attached to Unix practices and heritage (free software, open source) conceived? What are the theoretical developments to be drawn from it (for instance with the idea of open software)? The logical and mathematical foundations of Unix should be readdressed. Do the fundamental concepts of Unix have an ontological or metaphysical significance beyond the sole research aim of technical efficiency? What role do aesthetics play in the formulation of general principles and technical choices? How can we analyze programming languages such as C and its successors, scripts, software, and generally speaking, the proliferating source codes of Unix? How do we consider the system, the software environment, as well as the hardware in which Unix is implemented and executed? Such philosophical questions also cover the modalities of the transmission of Unix, extending to the investigation of the respective roles of theory and practice in the teaching of the system, the teaching of knowledge and tools underlying the system or supporting the system. *3. Unix heritage and ‘heritagization’* ** France is now the home to multiple initiatives taking place to build and preserve a material and immaterial heritage of computer science and technology – such as ‘Software Heritage’ at INRIA, a global software archive in progress. The Museum of Arts et Métiers gave impetus to the MINF initiative (‘Pour un Musée de l’informatique et du numérique’) and coordinates the ‘Patstec Mission’ dealing with contemporary scientific and technological heritage preservation, including computer science. At an international scale and with a grassroots perspective carried by the community of Unix users, the TUHS (The Unix Heritage Society) demonstrates the current interest in the specific heritage linked to Unix. We encourage reflections on this heritage and its specific features: - What is the place of Unix in the construction of computer science heritage? Is it possible to map Unix systems and their heritage, from the standpoint of machines, languages and software? What has already been collected? What corpus, data bases, and/or platforms with a patrimonial mission are concerned with Unix and to what purpose? - How are the questions of training, constitution and diffusion of a Unix culture incorporated in the effort to collect heritage? How do we evaluate and put forward the importance of immaterial heritage attached to Unix, considering the effects of community and memory in its history and for the writing of its history? - What are the practices and modalities advocated by the unixian heritage itself? What has been its influence on the field of computer engineering and research as well as diverse fields such as: popularization of science and technology, ‘hacker’ movements and many ‘maker’ practices today (Lallement, 2016)? *Schedules* Please send a one-page abstract (maximum 500 words) with a short biography by June 30, 2017 to: camille.paloque-berges at cnam.fr and loic.petitgirard at cnam.fr . Accepted contributions and speakers will be notified by July 15, 2017. *Organizing committee* Isabelle Astic (Musée des arts et métiers) Raphaël Fournier-S’niehotta (Cédric, Cnam) Pierre-Eric Mounier-Kuhn (CRM, Paris 1) Camille Paloque-Berges (HT2S, Cnam) Loïc Petitgirard (HT2S, Cnam) *Scientific committee * François Anceau (UMPC-LIP6)** Pierre Cubaud (Cédric, Cnam) Liesbeth de Mol (STL, Lille 3) Claudine Fontanon (CAK, EHESS) Gérald Kembellec (DICEN, Cnam) Baptiste Mélès (Archives Henri Poincaré, CNRS) Pierre Paradinas (Cédric, Cnam, SIF) Giuseppe Primiero (Middlesex University) Lionel Tabourier (LIP6, Paris 6)** *Institutional partners and support: * - Project « Hist.Pat.info.Cnam », HT2S, Cnam – Research program supported by the Excellence laboratory History and Anthropology of Knoweldge, Technics and Beliefs (HASTEC), and in partnership with the laboratories CEDRIC (Cnam), DICEN (Cnam), and the Center Alexandre Koyré (EHESS). - « Histoire de l’informatique » (« History of computing » seminar) seminar - (Musée des arts et métiers, CRM, Paris 1, UMPC-LIP6) - « Source code » seminar - (CNRS, Cnam, Université Paris 6). With support from the DHST/DLMPST for the History and Philosophy of Computing (HAPOC) *Bibliography * Kelty, Christopher M. 2008. /Two Bits: The Cultural Significance of Free Software/. Durham: Duke University Press Books. Lallement, Michel. 2016. /L’âge du faire, /Seuil. Mélès, Baptiste. 2003. « Unix selon l’ordre des raisons : la philosophie de la pratique informatique ». /Philosophia Scientiæ/17 (3): 181‑98. Salus, Peter H. 1994. /A quarter century of UNIX/. Addison-Wesley. Reading. Toomey, Warren. 2010. « First Edition Unix: Its Creation and Restoration ». /IEEE Annals of the History of Computing/ 32 (3): 74‑82. * * ** -------------- next part -------------- An HTML attachment was scrubbed... URL: From noel.hunt at gmail.com Fri Jun 23 15:56:25 2017 From: noel.hunt at gmail.com (Noel Hunt) Date: Fri, 23 Jun 2017 15:56:25 +1000 Subject: [TUHS] Obscure Blit menu data structure Message-ID: I was hoping someone on the list who remembers 'mhit.c' from the Blit library code could shed some light on some members of the 'NMitem' structure. I believe that 'mhit' (sometimes 'hmenunit') was written by Andrew Hume. The structure in question is this: typedef struct NMitem { char *text; char *help; struct NMenu *next; void (*dfn)(), (*bfn)(), (*hfn)(); long data; /* user only */ } NMitem; The three functions are called at different times when a menu is being traversed, but 'dfn' and 'bfn' are only called before a submenu is entered, and after a submenu is exited, respectively. 'hfn' is called whenever an item has been selected. I have never seen 'dfn' and 'bfn' used in any Bell Labs code so I was wondering what the rationale for their existence was. Noel Hunt -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Sun Jun 25 10:50:51 2017 From: random832 at fastmail.com (Random832) Date: Sat, 24 Jun 2017 20:50:51 -0400 Subject: [TUHS] What did cc -2 do? Message-ID: <1498351851.4029367.1020289456.6F4D64BC@webmail.messagingengine.com> Browsing the source for "cc" in v6 and v7, if invoked with -2 would replace crt0.o with crt2.o. If the -2 were followed by another character (probably intended to be -20), it would use crt20.o and use -l2 instead of -lc. These options seem to be undocumented, and I can't find any source code of these libraries or indication as to what the purpose was. From w.f.j.mueller at retro11.de Mon Jun 26 02:25:25 2017 From: w.f.j.mueller at retro11.de (Walter F.J. Mueller) Date: Sun, 25 Jun 2017 18:25:25 +0200 Subject: [TUHS] 211bsd: kernel panic after a 'here document' in tcsh Message-ID: Hi, two remarks on the issues around FPSIM and tcsh: I of course wondered by a line like mov $4..,r0 is accepted by 'as', I naively expected that this should cause an error. I didn't locate the 211bsd 'as' manual, so checked 7th Edition manuals, which can be found under https://wolfram.schneider.org/bsd/7thEdManVol2/ The assembler manual, see https://wolfram.schneider.org/bsd/7thEdManVol2/assembler/assembler.pdf states 6.1 Expression operators The operators are: (blank) when there is no operand between operands, the effect is exactly the same as if a ‘+’ had appeared. So the lexer sees two tokens $4. --> number . --> symbol for location counter and, because the default operator is '+', interprets this as mov $4. + . , r0 which ends up being a number in the 160000 to 177777 range. So 'as' is not to blame, works as designed. Noel Chippa wrote: > I'm fairly amazed that apparently nobody has run across one of these 4 before! > (Or, at least, not bothered to report it.) > I wonder how long that bug has been in the code? The answer is: this bug was in 211bsd all the time. Steven Schultz told me that that they simply didn't have a way to test FPSIM because all machines had FPP, and the only way of testing would have been to physically remove the FP11 from a 11/70. With best regards, Walter From richard at inf.ed.ac.uk Tue Jun 27 23:54:06 2017 From: richard at inf.ed.ac.uk (Richard Tobin) Date: Tue, 27 Jun 2017 14:54:06 +0100 (BST) Subject: [TUHS] What did cc -2 do? In-Reply-To: Random832's message of Sat, 24 Jun 2017 20:50:51 -0400 Message-ID: <20170627135406.21EAD137A42A@macaroni.inf.ed.ac.uk> > Browsing the source for "cc" in v6 and v7, if invoked with -2 would > replace crt0.o with crt2.o. If the -2 were followed by another character > (probably intended to be -20), it would use crt20.o and use -l2 instead > of -lc. > > These options seem to be undocumented, and I can't find any source code > of these libraries or indication as to what the purpose was. The "scc" man page for System V may be enlightening, as it mentions similarly-named files: NAME scc - C compiler for stand-alone programs SYNOPSIS scc [ +[ lib ] ] [ option ] ... [ file ] ... DESCRIPTION Scc prepares the named files for stand-alone execution. [...] FILES /lib/crt2.o execution start-off /usr/lib/lib2.a stand-alone library /usr/lib/lib2A.a +A configuration library /usr/lib/lib2B.a +B configuration library -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From david at kdbarto.org Wed Jun 28 02:19:15 2017 From: david at kdbarto.org (David) Date: Tue, 27 Jun 2017 09:19:15 -0700 Subject: [TUHS] Adventure shell / Doug Gwyn Message-ID: <126A55E2-CCEA-44D7-A0F3-574C9F2002CC@kdbarto.org> Does anyone here remember the Adventure Shell? Doug wrote it back in 83, and I just stumbled across a copy in an RCS directory. Invoked as ‘ash’ it was pretty clever. I’ve lost the instructions and help files, however I’ve got the main script. Back when people did weird things because it was fun. David From random832 at fastmail.com Wed Jun 28 03:35:13 2017 From: random832 at fastmail.com (Random832) Date: Tue, 27 Jun 2017 13:35:13 -0400 Subject: [TUHS] What did cc -2 do? In-Reply-To: <20170627135406.21EAD137A42A@macaroni.inf.ed.ac.uk> References: <20170627135406.21EAD137A42A@macaroni.inf.ed.ac.uk> Message-ID: <1498584913.364854.1023002800.3B8D3CB5@webmail.messagingengine.com> On Tue, Jun 27, 2017, at 09:54, Richard Tobin wrote: > The "scc" man page for System V may be enlightening, as it mentions > similarly-named files: Hmm. It seems that the truth is a little bit more convoluted than that, but it was a good starting point. The equivalent functionality in V7/usr/src/cmd/standalone uses "libsa" (in addition to, rather than instead of, libc) and srt0.o, and was used with a "cc+ld-stand" script which read as follows: cc -c -O -DSTANDALONE ../$1.c ld -s -o $1 srt0.o $1.o -lsa -lc rm $1.o The equivalent manpage in System III mentions crt20.o instead. System III scc invokes cc with "-2x" (System V uses -Z2). So, mystery solved, I guess, except for why it appears in the V6 (and V5, and V2) cc with no trace of the needed libraries, and V7 with the libraries having a different structure. My guess is that the V7 library structure was a post-V6 change that didn't make it into USG Unix. My assumption is that it's dead code at that point. The v7 cc+ld-stand script doesn't seem to have been suitable for multi-file programs, either - no other version has this script, either (Ultrix and BSD seem to both have standalone systems derived from it, but both just have the relevant cc and ld commands in their makefiles) So, my theorized timeline: This began as an internal tool in V2*. USG Unix and V7 diverged, and V7 effectively abandoned the use of a magic flag and hardcoded library names in "cc" (but for some reason retained the actual associated functionality in "cc" itself, where it survived into Ultrix 3.1 and 3BSD but not 4BSD). Ultrix and BSD took V7's version of the functionality. *specifically, it appears in V2/cmd/cc.c which comes from s1-bits. It does not appear in V2/c/ncc.c which comes from last1120c. > NAME > scc - C compiler for stand-alone programs > > SYNOPSIS > scc [ +[ lib ] ] [ option ] ... [ file ] ... > > DESCRIPTION > Scc prepares the named files for stand-alone execution. > [...] > > FILES > /lib/crt2.o execution start-off > /usr/lib/lib2.a stand-alone library > /usr/lib/lib2A.a +A configuration library > /usr/lib/lib2B.a +B configuration library From chet.ramey at case.edu Wed Jun 28 03:39:30 2017 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 27 Jun 2017 13:39:30 -0400 Subject: [TUHS] Adventure shell / Doug Gwyn In-Reply-To: <126A55E2-CCEA-44D7-A0F3-574C9F2002CC@kdbarto.org> References: <126A55E2-CCEA-44D7-A0F3-574C9F2002CC@kdbarto.org> Message-ID: <236a5f12-a394-ab44-22be-4a3c6f2598f1@case.edu> On 6/27/17 12:19 PM, David wrote: > Does anyone here remember the Adventure Shell? For a long time (through bash-4.2), I shipped it as one of the scripting examples in the bash distribution. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://cnswww.cns.cwru.edu/~chet/ From akosela at andykosela.com Wed Jun 28 09:00:31 2017 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 27 Jun 2017 18:00:31 -0500 Subject: [TUHS] Adventure shell / Doug Gwyn In-Reply-To: <126A55E2-CCEA-44D7-A0F3-574C9F2002CC@kdbarto.org> References: <126A55E2-CCEA-44D7-A0F3-574C9F2002CC@kdbarto.org> Message-ID: On Tuesday, June 27, 2017, David wrote: > Does anyone here remember the Adventure Shell? > > Doug wrote it back in 83, and I just stumbled across a copy in an RCS > directory. > > Invoked as ‘ash’ it was pretty clever. I’ve lost the instructions and > help files, however I’ve got the main script. > > Back when people did weird things because it was fun. > > There is also the New Adventure Shell project. http://nadvsh.sourceforge.net/ --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Jun 28 10:07:09 2017 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 28 Jun 2017 10:07:09 +1000 (EST) Subject: [TUHS] Adventure shell / Doug Gwyn In-Reply-To: <126A55E2-CCEA-44D7-A0F3-574C9F2002CC@kdbarto.org> References: <126A55E2-CCEA-44D7-A0F3-574C9F2002CC@kdbarto.org> Message-ID: On Tue, 27 Jun 2017, David wrote: > Does anyone here remember the Adventure Shell? I remember it well :-) "THROW TOWARDS PRINTER" (I think) would print it, "SAY xxx" would "echo xxx" etc... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."