using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Muzaffer Kal on 5 Mar 2010 12:15 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 5 Mar 2010 12:16 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 5 Mar 2010 13:57 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 5 Mar 2010 14:03 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 5 Mar 2010 14:44
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) |