using an FPGA to emulate a vintage computer
in [FPGA]
|
From: (see below) on 24 Feb 2010 19:16 On 24/02/2010 23:55, in article 1bmxyy42ag.fsf(a)snowball.wb.pfeifferfamily.net, "Joe Pfeiffer" <pfeiffer(a)cs.nmsu.edu> wrote: > When I was an undergrad I spent some time programming FORTRAN on a > Harris /6 (I think it was a /6 -- there's something nagging at the back > of my mind that says it may have been a /7). Anyway, reading the manual > I discovered that return addresses were stacked, and immediately jumped to > the conclusion that it could do recursion. It turned out that local > variables were static... which meant I spent a *long* time figuring out > why my program was producing completely nonsensical results. > > As Al Stewart once sang, "I was jumping to conclusions, and one of them > jumped back." People who assumed that FORTRAN local variables *must* be static got jumped on from the opposite direction when they used FORTRAN compilers that actually did put them on the stack, as the ANS FORTRAN standard was carefully worded to permit. -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: rickman on 24 Feb 2010 20:40 On Feb 22, 3:28 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > In comp.arch.fpga rickman <gnu...(a)gmail.com> wrote: > (big snip) > > > 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. > > It depends, somewhat, on the programmer. In K&R C, you couldn't > pass a struct, but instead a pointer to a struct. That kept > the stack a little smaller, at least. With C89, as with K&R, > arrays (including automatic, allocated on the stack) had a > constant dimension. If I remember right, C99 added the ability > to dimension local automatic (stack) arrays with variables. > (Previously, a pointer on the stack and malloc() would have > been used, along with the requirement to remember free().) > > > A language like > > Forth, on the other hand, can get by with a very small hardware stack > > because the stack usage tends to be minimal and subroutine nesting > > does not automatically add to the data stack depth. Instead, often > > parameters that are passed into one routine are also passed onto the > > next without duplication until they are consumed by the calculations > > that need them. In c every call copies every piece of data needed for > > the lower level code creating stack "bloat" if you will. > > If you only pass pointers, it isn't so bad... > > -- glen The problem is not just that the data on the stack is larger, but that the data that is passed into one function often has to be passed into functions that this function calls. As the routines nest, the data is typically duplicated on the stack over and over. In Forth the stack is normally juggled and duplication is minimal, so hardware stacks can be as small as 16 words and still be very effective. Rick
From: Charles Richmond on 24 Feb 2010 23:27 glen herrmannsfeldt wrote: > In comp.arch.fpga Charles Richmond <frizzle(a)tx.rr.com> wrote: >> (see below) wrote: >>> On 23/02/2010 17:48, in article >>> 4178548f-5618-49dd-ad72-008bdb53ed3b(a)z25g2000vbb.googlegroups.com, "Eric >>> Chomko" <pne.chomko(a)comcast.net> wrote: >>> [snip...] [snip...] [snip...] >>>> Speaking of ALGOL parameter passing, what's a "thunk"? > >>> A thunk is the anonymous function (pair) described above. > >> A "thunk" was a method of implementing "call by name". > > Much of the discussion about ALGOL, including this, is in the > past tense. As ALGOL60 hasn't changed recently, and the compilers > still exist, even if new ones aren't being written, it seems to > me that present tense is fine. > > A "thunk" is a method of implementing "call by name". > > More to the hardware side, an archetecture still exists even > if no implementations of it exist. (Though in most cases at > least one still does.) The PDP8 still IS a 12 bit machine, > even if you implement it in an FPGA. > A "thunk" was *and* is a method for implementing "call by name". But a compiler providing "thunks" has *not* been written for some time now. So there is *some* justification for using past tense. Once something exists, the *potential* for actually re-creating it continues to exist. I accept that; indeed, I *celebrate* that!!! These things are now curiosities... and I *am* curious about them. Unfortunately, they have long ago lost their "gee whiz" value. ISTM that it is sad how quickly new technology is absorbed into the psyche and loses its "gee whiz" value. :-( -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Charles Richmond on 24 Feb 2010 23:32 Eric Chomko wrote: > On Feb 23, 2:07 pm, "(see below)" <yaldni...(a)blueyonder.co.uk> wrote: >> On 23/02/2010 17:52, in article >> 3ec03225-3a0f-4bcd-9db1-51201d1b3...(a)w12g2000vbj.googlegroups.com, "Eric >> >> Chomko" <pne.cho...(a)comcast.net> wrote: >>> 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. >> Just the usual red tape: return address, frame pointer of caller; and either >> a static pointer or some housekeeping for 'display' registers (if used) to >> access non-locals. But bear in mind that in decent languages arrays are >> storable values, so a value array parameter gets copied in toto, unlike C. >> > > Are you saying that C doesn't implement true recursion? I have only > used recursion in college and not with C. ALGOL, SIMPL-T and LISP were > the only languages I used to write recursive algorithms. > C does *not* support passing an array "by value", only "by reference". You can encapsulate an array in a struct and pass the struct "by value". C *does* support recursion. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+
From: Charles Richmond on 24 Feb 2010 23:38
Joe Pfeiffer wrote: > > [snip...] [snip...] [snip...] > > You forgot to mention local variables are in the activation record. > > When I was an undergrad I spent some time programming FORTRAN on a > Harris /6 (I think it was a /6 -- there's something nagging at the back > of my mind that says it may have been a /7). Anyway, reading the manual > I discovered that return addresses were stacked, and immediately jumped to > the conclusion that it could do recursion. It turned out that local > variables were static... which meant I spent a *long* time figuring out > why my program was producing completely nonsensical results. > > As Al Stewart once sang, "I was jumping to conclusions, and one of them > jumped back." I am *not* familiar with a Harris /6 or Harris /7. In the early 80's, I worked on a Harris 800 using the VOS operating system and FORTRAN 77. ISTR that each user-written subroutine and function reserved a word of memory at the beginning of the routine. This word was used to store the return address, and an indirect branch was done through this word to affect the return. Harris bought out the Datacraft computer company, and had a 500, an 800, and a 1200 with similar instruction sets. ISTR that the CPU's were implemented with bit-sliced microprocessors. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+ |