From: Ahem A Rivet's Shot on 5 Mar 2010 02:47 On Thu, 04 Mar 2010 16:45:40 -0500 Peter Flass <Peter_Flass(a)Yahoo.com> wrote: > I've said before, C started out as a fairly simple and clean language, > with possibly a few rough spots. Unfortunately instead of accepting it > on its own terms, and maybe coming up with "D", people tried to turn it This also happened read about D here http://www.digitalmars.com/d/ -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
From: Quadibloc on 5 Mar 2010 11:58 On Mar 4, 1:20 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > Does anyone know if the information needed to do that still exists? I suspect it was _very_ closely guarded back in the day, because it would have been a matter of very serious concern had the Russians been able to make a 360/195 equivalent to top out their RJAD/EC line. So I'm thinking more along the line of a design from scratch to match the public specifications, working from the 360/91 descriptions in the open literature, and adding a cache (which shouldn't be too difficult, there being caches on OpenCores). I'm not saying *I* could do stuff like that on my very own, but there's a lot out there one could use as a starting point. John Savard
From: Quadibloc on 5 Mar 2010 12:07 On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: > No, he's saying that C doesn't really implement an array type, the > var[offset] syntax is just syntactic sugar for *(var + offset) which is why > things like 3[x] work the same as x[3] in C. Um, no. x = y + 3 ; in a C program will _not_ store in x the value of y plus the contents of memory location 3. On a big-endian machine, long int x[5] ; x[0] = 3 ; x[1] = 12 ; y = x[0] ; or, on a little-endian machine, long int x[5] ; x[1] = 3 ; x[0] = 12 ; y = x[1] ; will not result in zero being stored in y, since a long int variable occupies more than one byte in storage, and hence the two assignments are being made to overlapping variables. Yes, C doesn't do _bounds checking_, but that is a far cry from "syntactic sugar for variable plus address offset". John Savard
From: Quadibloc on 5 Mar 2010 12:09 On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: > PL/I can be, but doesn't have to be. If the arguments of a procedure > match the parameters, only the argument address (and possibly a > descriptor address for strings structures, and arrays) is passed. Doesn't PL/I (or, rather, normal implementations thereof) support separate compilation of subroutines, just like FORTRAN and COBOL? John Savard
From: Quadibloc on 5 Mar 2010 12:14
On Feb 22, 2:53 pm, Eric Chomko <pne.cho...(a)comcast.net> wrote: > This was pre-RISC days and the whole computer > architecture idea > based upon a high-level language never really took off. Nor did the > use of a medium > level language like Forth as far as I can tell. Well, naturally not. Both of those ideas got you less performance per dollar than the use of a conventional architecture, with compilation by a highly- optimizing FORTRAN compiler. I mean, computer cycles cost real money in those days. Later on, in the microcomputer era, the even less efficient use of interpreters like BASIC was popular because it was an easy way to bridge the gap between what the microprocessors could do, and what was convenient for people to program in. But serious applications - which, in the case of home computers, largely meant video games - were programmed in assembler, until things improved to the point where C was an alternative. John Savard |