using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Anne & Lynn Wheeler on 5 Mar 2010 15:12 Quadibloc <jsavard(a)ecn.ab.ca> writes: > 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. 370/195 had some extra instructions & instruction retry added to improve reliability. 195 had 64 instruction pipeline and imprecise interrupts. 195 didn't have branch prediction or speculative execution ... so branches (except for special case loop within pipeline) drained the pipeline. peak-speed was 10mips ... but most codes ran at half that because of the frequency of branches draining pipeline. there was effort to do form of hyperthreading ... looking like multiprocessor with two instruction streams ... one-bit tag indicating which i-stream an instruction was associated with; basically same pipeline, same execution units ... but having two i-streams had better chance of running at peak thruput. I wasn't directly involved in the hardware ... just got brought in to look at running multiprocessor kernel/software for the machine. 195 never got virtual memory. SJR had 370/195 up thru end of 1978 running MVT. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: Peter Flass on 5 Mar 2010 17:54 Quadibloc wrote: > 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? > Yes, but the calling sequence among PL/I programs passes information on string lengths, array bounds, etc. You have to dumb it down to call other languages. For example, you can code: a: PROCEDURE( array ); DECLARE array (*) CHARACTER(*); DO i=1 to HBOUND(array); DO j=1 TO LENGTH(array(i)); ... END; END; where both the upper limit of "array" is passed along with the string length of the element.
From: Quadibloc on 6 Mar 2010 04:58 On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...(a)eircom.net> wrote: > No but x = *(y + 3) will store in x the contents of the memory > location at 3 + the value of y just as x = y[3] will and x = 3[y] will, > which is what I stated. You missed out the all important * and ()s. Intentionally. My point was that, while there is _some_ truth to the claim that C arrays tread rather lightly on the ground of hardware addressing, the claim that C doesn't have arrays at all, and the C array subscript operator does nothing at all but add two addresses together... is not *quite* true. If C doesn't have "real" arrays, it at least makes a rather good attempt to simulate them. Unless one's standards are such that FORTRAN doesn't quite have "real" arrays either, and you need to go to Pascal for real arrays, there isn't that much to complain about in the case of C. John Savard
From: Quadibloc on 6 Mar 2010 05:01 On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...(a)cs.nmsu.edu> wrote: > Quadibloc <jsav...(a)ecn.ab.ca> writes: > > 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". > > I'm not quite sure what the point of your example is, somebody who is > better at programming languages than me would have to evaluate the claim > that C arrays aren't arrays. But: > > #include <stdio.h> > int main() > { > int a[4]; > > printf("a[2] at 0x%8x\n", &(a[2])); > printf("2[a] at 0x%8x\n", &(2[a])); > printf("(a+2) is 0x%8x\n", a+2); > printf("(2+a) is 0x%8x\n", 2+a); > > } > > [pfeiffer(a)snowball ~/temp]# ./awry > a[2] at 0xbfff97b8 > 2[a] at 0xbfff97b8 > (a+2) is 0xbfff97b8 > (2+a) is 0xbfff97b8 The 2[a] syntax actually *works* in C the way it was described? I am astonished. I would expect it to yield the contents of the memory location a+&2 assuming that &2 can be persuaded to yield up the location where the value of the constant "2" is stored. Evidently there is some discrepancy between C and FORTRAN. John Savard
From: Quadibloc on 6 Mar 2010 05:03
On Mar 5, 3:54 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: > Quadibloc wrote: > > 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? > > Yes, but the calling sequence among PL/I programs passes information on > string lengths, array bounds, which is why the "bloat" is unavoidable in PL/I, not unnecessary, you had previously claimed and as I was trying to contradict. Yes, I'm well aware PL/I does not use the standard S-type calling sequence. John Savard |