glen herrmannsfeldt <g...@ugcs.caltech.edu>
writes:
>In comp.arch.fpga rickman <g...@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().)

Some C implementations supported alloca() which would allocate
on the stack (and would be automatically free'd on return).

A minimal C stack frame is the return instruction pointer, with
arguments passed in registers.

scott

On Feb 22, 12:27=A0pm, rickman
<gnu...@gmail.com> wrote:

> A hardware stack for C is a bit of a problem. =A0C 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

On 23/02/2010 09:39, in article
e...@v25g2000yqk.googlegroups.com,
"Quadibloc" <j...@ecn.ab.ca> wrote:

> On Feb 22, 12:27 pm, rickman <gnu...@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

On Feb 22, 5:10=A0pm, glen herrmannsfeldt
<g...@ugcs.caltech.edu> wrote:
> In comp.arch.fpga Eric Chomko <pne.cho...@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. =A0(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. =A0Without the RECURSIVE attribute, it
> probably still does.
>
> Other than passing of arguments, it depends on how you allocate
> your variables. =A0PL/I has the STATIC attribute which will keep
> variables off the stack, as does C. =A0Be careful with recursion, though.
> For ALGOL, maybe you need internal procedures using variables from
> outside, and to minimize actual local variables. =A0PL/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

On Feb 22, 5:53=A0pm, Peter Flass
<Peter_Fl...@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. =A0If the arguments of a procedure
> match the parameters, only the argument address (and possibly a
> descriptor address for strings structures, and arrays) is passed. =A0If
> the argument doesn't match, the compiler nicely copies it to a "dummy
> argument" that does. =A0As 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.

On Feb 23, 7:39=A0am, "(see below)"
<yaldni...@blueyonder.co.uk> wrote:
> On 23/02/2010 09:39, in article
> e59b10e9-83f7-4fb6-8ecf-a9d8fd13f...@v25g2000yqk.googlegroups.com,
>
> "Quadibloc" <jsav...@ecn.ab.ca> wrote:
> > On Feb 22, 12:27 pm, rickman <gnu...@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 da=
ta
> flow and control flow analyses. The Kidsgrove compiler made a basic but n=
ot
> 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.

On 23/02/2010 17:48, in article
4...@z25g2000vbb.googlegroups.com, "Eric
Chomko" <p...@comcast.net> wrote:
> The thing about ALGOL parameter passing was that there was four ways
> to do it according to the ALGOL 60 spec.

No. Algol 60 had value parameters and name parameters only.

A name parameter was actually an anonymous function, re-evaluated at every
use within the procedure; or it could be a pair of such functions, one
member of the pair delivering an L value and the other one an R value.
These functions had to be generated by the compiler from the actual
parameter expression expressions.

The above refers to parameters of storable types; of course there were other
kinds of parameter such as switches, strings, procedures and (named)
functions to which the value/name distinction did not apply.
 
> 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...

Algol W had value, result, value-result and name modes; but no reference
parameters; plus procedures and (named) functions.

Algol 68 arguably had only storable value parameters, but the value passed
could be of a reference type (this was quite well handled in Algol 68, but
soon degenerated into C's semantic sludge).

> Speaking of ALGOL parameter passing, what's a "thunk"?

A thunk is the anonymous function (pair) described above.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

On 23/02/2010 17:52, in article
3...@w12g2000vbj.googlegroups.com, "Eric
Chomko" <p...@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.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

On 23/02/2010 17:57, in article
5...@z25g2000vbb.googlegroups.com, "Eric
Chomko" <p...@comcast.net> wrote:

> On Feb 23, 7:39 am, "(see below)" <yaldni...@blueyonder.co.uk>
wrote:
>> On 23/02/2010 09:39, in article
>> e59b10e9-83f7-4fb6-8ecf-a9d8fd13f...@v25g2000yqk.googlegroups.com,
>> 
>> "Quadibloc" <jsav...@ecn.ab.ca> wrote:
>>> On Feb 22, 12:27 pm, rickman <gnu...@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.

That was Randell & Russell's classic documentation of KDF9 Whetstone Algol.

It was used as a manual for the implementation of the Whetstone dialect of
Algol 60 on many other architectures, including the EE DEUCE, the Ferranti
Pegasus, the NPL ACE, the EE KDF6, the Soviet Minsk range, the EE System
4/50, the IBM System 360/25, the Phillips PRS8000, and the Indian ECIL
TDC-316.

There is a lot more information about Algol 60 and the KDF9 implementations
at <http://sw.ccs.bcs.org/CCs/KDF9/Wichmann/index.html>;.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

(see below) wrote:
> On 23/02/2010 17:48, in article
> 4...@z25g2000vbb.googlegroups.com, "Eric
> Chomko" <p...@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".

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+