using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Patrick Scheible on 6 Mar 2010 16:58 Walter Bushell <proto(a)panix.com> writes: > In article <20100305171635.e538ef18.steveo(a)eircom.net>, > Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: > > > 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. > > No, that will compare x and the right val. > > = is a comparasion operator in c. I think you've got them mixed up. = is the assignment operator, == is the comparison operator. -- Patrick
From: Joe Pfeiffer on 6 Mar 2010 17:40 Walter Bushell <proto(a)panix.com> writes: > In article <20100305171635.e538ef18.steveo(a)eircom.net>, > Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: > >> 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. > > No, that will compare x and the right val. > > = is a comparasion operator in c. Umm..... no. It's not. It's the assignment operator. -- 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)
From: Peter Flass on 6 Mar 2010 17:43 Walter Bushell wrote: > In article <20100305171635.e538ef18.steveo(a)eircom.net>, > Ahem A Rivet's Shot <steveo(a)eircom.net> wrote: > >> 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. > > No, that will compare x and the right val. > > = is a comparasion operator in c. > '=' is assignment, '==' is comparison.
From: Rick on 6 Mar 2010 19:40 On Mar 4, 1:45 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: > Eric Chomko wrote: > > On Mar 3, 7:06 pm, Greg Menke <guse...(a)comcast.net> wrote: > >> Peter Flass <Peter_Fl...(a)Yahoo.com> writes: > >>> Michael Wojcik wrote: > >>>> Peter Flass wrote: > >>>>> Hey! C's finally caught up to PL/I. Only took them 50 years, and then > >>>>> of course all the features are just tacked-on in true C fashion, instead > >>>>> of thought-through. > >>>> Well, that's rather insulting to the members of WG14, who spent a > >>>> decade designing those features. Fortunately, they published the > >>>> Rationale showing that, in fact, they were thought through.[1] And a > >>>> great deal of documentation describing the process is available in the > >>>> archives.[2] > >>>> If you'd care to show why you think otherwise, perhaps there would be > >>>> some grounds for debate. > >>> "The flexible array must be last"? > >>> "sizeof applied to the structure ignores the array but counts any > >>> padding before it"? > >>> C is a collection of ad-hoc ideas. WG14 may have put a great deal of > >>> thought into how to extend it without breaking the existing mosh, but > >>> that's my point, it's still a mosh. > >> iostream formatting operators, because we really need more operator > >> overloading and no enhancements are too bizarre in service of making > >> everything, (for particular values of everything), specialized? > > >> Oh but wait, you can compile, install and dig your way through Boost so > >> as to avoid the fun & games of vanilla iostream. > > >> Thank goodness printf and friends are still around. > > > More generally when speaking about C++, than goodness C is still > > around. > > 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 > into a real 3GL, but then it gets in its own way. It's lots of fun > reading some of the Gnu stuff to see a language less readable than APL.- Hide quoted text - > > - Show quoted text - I'm pretty much in Rip Van Winkle mode. Took a C class back in 1988 for the fun of it, managed to get an A in it, and kind of liked it. Twenty years later I pop my head up and it might as well be Hieroglyphs. Funny thing<to me> is the people running the show or part of it love the way it evolved. I'm definately in the minority. *BUT* not trying to wrap the drift back to FPGA or anything since I am frequently guilty of drift myself, it is all interesting. What I meant was more along the lines of hardware that would make a language writer's job easier, a language that would execute faster, an implementation that would be more robust. Just as an example since the link I posted was a ref to the 65C02: The hardware stack is only 256 bytes so passing parameters on the stack can run into problems. You can have a software stack but branches have to be within ~+-128. This leaves you with a software stack => 16 bit pointers, 64k limit, and slower then the other tools. One of the other old processors from my stone knives and bear skin days was the RCA1802. It had IMHO a great feature for the calling subroutines. Anyone of the 16 general purpose registers could be made the program counter with a single instruction. The author of that web page decoded instructions on the buss to implement his own set of register and instructions. IIRC he called one register 'W' and it acted as an extended program counter so the memory could be expanded to ~4 megs. Of course he did a lot more then that with adding useful instructions. I was just thinking if I wanted to have a faster 'C one of the things I would like to do is implement the single instruction PC change. If for example you had say 255 external 24 bit hardware registers in a FPGA that would function as a PC you could have that many subroutines implemented in a 2 byte instruction i.e. op code for next byte will be PC register selection followed by a single byte. I would have to look at the op codes available but you may be able to implement ~16 subroutine calls in a single byte. I think it could be done on the cheap and simple with a small GAL and maybe a fast static ram to contain the microcode and function as the W and PC registers. The 16 external registers would probably be enough if you choose the 16 most called routines from the runt time code. You could also implement runtime read only memory, memory moves by blit, pattern matching for things like string search functions in a form similar to blit, a second 'hardware stack' separate from main memory. Of course it comes back to my original statement that people could just tell me to throw a Pentium at the problem and it would be valid point. Rick
From: Charles Richmond on 6 Mar 2010 19:48
Peter Flass 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, 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. ISTM that one of the design goals of C was to make function calls have a smaller overhead that other HLL's. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+ |