From: Muzaffer Kal on
On Fri, 5 Mar 2010 09:07:31 -0800 (PST), Quadibloc <jsavard(a)ecn.ab.ca>
wrote:

>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.

Of course not, given that there is dereference operator anywhwere. On
the other hand

x = y + *((int*)3);

would do what you want. You need to get that '*' in there.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
From: Ahem A Rivet's Shot on
On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
Quadibloc <jsavard(a)ecn.ab.ca> wrote:

> 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.

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.

--
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: glen herrmannsfeldt on
In comp.arch.fpga Quadibloc <jsavard(a)ecn.ab.ca> wrote:
> On Mar 4, 1:20?pm, glen herrmannsfeldt <g...(a)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
From: glen herrmannsfeldt on
In comp.arch.fpga Quadibloc <jsavard(a)ecn.ab.ca> 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?

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
From: Joe Pfeiffer on
Quadibloc <jsavard(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
--
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)