In comp.arch.fpga Quadibloc
<j...@ecn.ab.ca> wrote:
> On Mar 4, 1:20?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
(regarding the design of the 360/195 or 360/91)
>> 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.

An important part of the design is the Earle latch, which combines
one level of logic with the latch function.  That is, what is
sometimes called a transparent latch, instead of the edge triggered
D flip-flop commonly available in FPGAs.  There is a lot of literature
on the floating point unit, though I don't know if near enough to
reconstruct one.  For the rest of the processor, I have seen
very little.

I believe that there is some effort towards implementing the
360/30 harware to execute actual 360/30 microcode.  

-- glen

-- glen

In comp.arch.fpga Quadibloc
<j...@ecn.ab.ca> wrote:
> On Feb 22, 3:53?pm, Peter Flass <Peter_Fl...@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?

I missed the beginning of this thread, but...

Yes, PL/I, at least IBM's implementations, support separate
compilation.  In some cases that requires declaring the argument
types in the calling routine such that appropriate conversion
can be done.   Otherwise, it would be way too hard to use
many routines, with constants having the attributes in which
they are written.  If a routine expected fixed bin(31,0),
for example, you couldn't call it with  1, which would be
fixed dec(1), but would have to use 0000000000000000000000000000001B
instead.  Declaring it as needing fixed bin(31,0), allows the
compiler to do the conversion either at compile or run time.

-- glen

Quadibloc <j...@ecn.ab.ca> writes:

> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@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@snowball ~/temp]# ./awry
a[2] at 0xbfff97b8
2[a] at 0xbfff97b8
(a+2) is 0xbfff97b8
(2+a) is 0xbfff97b8
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Quadibloc <j...@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

Quadibloc wrote:
> On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...@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.

On Mar 5, 10:16=A0am, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:

> =A0 =A0 =A0 =A0 No but x =3D *(y + 3) will store in x the contents of the=
 memory
> location at 3 + the value of y just as x =3D y[3] will and x =3D 3[y] wil=
l,
> 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

On Mar 5, 12:44=A0pm, Joe Pfeiffer
<pfeif...@cs.nmsu.edu> wrote:
> Quadibloc <jsav...@ecn.ab.ca> writes:
> > On Feb 26, 4:56=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> >> =A0 =A0 =A0 =A0 No, he's saying that C doesn't really implement an arr=
ay type, the
> >> var[offset] syntax is just syntactic sugar for *(var + offset) which i=
s why
> >> things like 3[x] work the same as x[3] in C.
>
> > Um, no.
>
> > x =3D 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] =3D 3 ;
> > x[1] =3D 12 ;
> > y =3D x[0] ;
>
> > or, on a little-endian machine,
>
> > long int x[5] ;
> > x[1] =3D 3 ;
> > x[0] =3D 12 ;
> > y =3D 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. =A0But:
>
> #include <stdio.h>
> int main()
> {
> =A0 =A0 int a[4];
>
> =A0 =A0 printf("a[2] at 0x%8x\n", &(a[2]));
> =A0 =A0 printf("2[a] at 0x%8x\n", &(2[a]));
> =A0 =A0 printf("(a+2) is 0x%8x\n", a+2);
> =A0 =A0 printf("(2+a) is 0x%8x\n", 2+a);
>
> }
>
> [pfeiffer@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

On Mar 5, 3:54=A0pm, Peter Flass
<Peter_Fl...@Yahoo.com> wrote:
> Quadibloc wrote:
> > On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>
> >> PL/I can be, but doesn't have to be. =A0If the arguments of a procedur=
e
> >> 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 =A0lengths, 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

In comp.arch.fpga Quadibloc
<j...@ecn.ab.ca> wrote:
(snip)

>> [pfeiffer@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.

I believe the standard requires it.  The subscript operator, [],
is defined such that a[b] is equivalent to *(a+b).  

a[b] is *(a+b) is *(b+a) is b[a]

It gets even more interesting with more subscripts, but still works.

-- glen

Quadibloc wrote:
> On Mar 5, 3:54 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>> Quadibloc wrote:
>>> On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...@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.
>


Yes, but is it bloat?  When I've converted C functions that work with 
arrays, most of them need to be passed the [address of the] array and 
the upper bound.  The first thing I do is get rid of the latter, since 
it's handled automatically, but it's necessary one way or the other, so 
why not have the language do it?