using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Quadibloc on 23 Feb 2010 04:39 On Feb 22, 12:27 pm, rickman <gnu...(a)gmail.com> wrote: > A hardware stack for C is a bit of a problem. C tends to need a > rather large stack because of the stack frames used. What could happen, though, on a computer with a small hardware stack is that the compiler would use a software stack for things like subroutine calls (which must always work, no matter how deeply they are nested) and use the hardware stack for things it can control - such as the layers of parentheses in assignment statements. That, for example, is presumably how one would go about writing a C compiler for a KDF 9. John Savard
From: (see below) on 23 Feb 2010 07:39 On 23/02/2010 09:39, in article e59b10e9-83f7-4fb6-8ecf-a9d8fd13f055(a)v25g2000yqk.googlegroups.com, "Quadibloc" <jsavard(a)ecn.ab.ca> wrote: > On Feb 22, 12:27�pm, rickman <gnu...(a)gmail.com> wrote: > >> A hardware stack for C is a bit of a problem. �C tends to need a >> rather large stack because of the stack frames used. > > What could happen, though, on a computer with a small hardware stack > is that the compiler would use a software stack for things like > subroutine calls (which must always work, no matter how deeply they > are nested) and use the hardware stack for things it can control - > such as the layers of parentheses in assignment statements. > > That, for example, is presumably how one would go about writing a C > compiler for a KDF 9. The way the Algol 60 compilers on KDF9 worked is well documented. The Whetstone compiler generated its own Algol-oriented byte code, which is very similar to the slightly later B6500 machine code. The Kidsgrove and EGDON compilers generated KDF9 machine code. Managing the hardware stacks difficult, as it would have needed global data flow and control flow analyses. The Kidsgrove compiler made a basic but not very successful attempt at this. See <http://sw.ccs.bcs.org/KidsgroveAlgol/INDEX.HTM>. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Eric Chomko on 23 Feb 2010 12:48 On Feb 22, 5:10 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > In comp.arch.fpga Eric Chomko <pne.cho...(a)comcast.net> wrote: > (snip) > > > I'm pretty sure ALGOL and PL/I are far worse WRT to stack > > bloat than is C. > > ALGOL, PL/I, and C pretty much require local variables to > be automatic. (PL/I procedures without the RECURSIVE attribute > might get away with static allocation.) > > Fortran up through Fortran 77 allowed local variables to be > statically allocated. Without the RECURSIVE attribute, it > probably still does. > > Other than passing of arguments, it depends on how you allocate > your variables. PL/I has the STATIC attribute which will keep > variables off the stack, as does C. Be careful with recursion, though. > For ALGOL, maybe you need internal procedures using variables from > outside, and to minimize actual local variables. PL/I can easily > generate temporary variables, including arrays. The thing about ALGOL parameter passing was that there was four ways to do it according to the ALGOL 60 spec. As I recall from my Comp Sci days at U of MD, ALGOL used call by value, call by reference, call by value/result, and call by name. I'll tell you I still didn't understand why more than call by value and call by reference are needed. Anyway... Speaking of ALGOL parameter passing, what's a "thunk"? Anyone get that and they get a gold star for the day. Suffice to say, my prof back in the day (Dr. John Gannon, may he RIP), was the sort of guy that knew everything about everything thing when it came to computer language translation, even the trivia! Eric
From: Eric Chomko on 23 Feb 2010 12:52 On Feb 22, 5:53 pm, Peter Flass <Peter_Fl...(a)Yahoo.com> wrote: > Eric Chomko wrote: > > > I'm pretty sure ALGOL and PL/I are far worse WRT to stack bloat than > > is C. > > 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. If > the argument doesn't match, the compiler nicely copies it to a "dummy > argument" that does. As usual, the programmer needs to have some idea > what's going on. But an ALGOL "activation record" (stack frame) had a lot more than that. As I recall, they copied a lot more just pointers and parameter values.
From: Eric Chomko on 23 Feb 2010 12:57
On Feb 23, 7:39 am, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote: > On 23/02/2010 09:39, in article > e59b10e9-83f7-4fb6-8ecf-a9d8fd13f...(a)v25g2000yqk.googlegroups.com, > > "Quadibloc" <jsav...(a)ecn.ab.ca> wrote: > > On Feb 22, 12:27 pm, rickman <gnu...(a)gmail.com> wrote: > > >> A hardware stack for C is a bit of a problem. C tends to need a > >> rather large stack because of the stack frames used. > > > What could happen, though, on a computer with a small hardware stack > > is that the compiler would use a software stack for things like > > subroutine calls (which must always work, no matter how deeply they > > are nested) and use the hardware stack for things it can control - > > such as the layers of parentheses in assignment statements. > > > That, for example, is presumably how one would go about writing a C > > compiler for a KDF 9. > > The way the Algol 60 compilers on KDF9 worked is well documented. > The Whetstone compiler generated its own Algol-oriented byte code, which is > very similar to the slightly later B6500 machine code. > > The Kidsgrove and EGDON compilers generated KDF9 machine code. > Managing the hardware stacks difficult, as it would have needed global data > flow and control flow analyses. The Kidsgrove compiler made a basic but not > very successful attempt at this. > > See <http://sw.ccs.bcs.org/KidsgroveAlgol/INDEX.HTM>. > I am more familiar with the Norway University version of ALGOL on a UNIVAC 1100 series machine. NU-ALGOL it was called. I sold a book called "ALGOL Implementation" based upon the Whetsone compiler on eBay about a decade ago. Got a pretty good price for it as well as I recall. |