From: Ahem A Rivet's Shot on
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
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
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
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
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