Re: another C-like language? was Compilers :)

Keith Thompson <Keith.S.Thompson+u@gmail.com>
Mon, 09 Jan 2023 11:24:07 -0800

          From comp.compilers

Related articles
[7 earlier articles]
Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-05)
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-06)
Re: another C-like language? was Compilers :) marblypup@yahoo.co.uk (marb...@yahoo.co.uk) (2023-01-07)
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-08)
Re: another C-like language? was Compilers :) DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-01-09)
Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-09)
Re: another C-like language? was Compilers :) Keith.S.Thompson+u@gmail.com (Keith Thompson) (2023-01-09)
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-10)
Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-10)
Re: another C-like language? was Compilers :) tkoenig@netcologne.de (Thomas Koenig) (2023-01-11)
Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (2023-01-11)
Re: another C-like language? was Compilers :) findlaybill@blueyonder.co.uk (Bill Findlay) (2023-01-11)
Re: another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (2023-01-11)
[6 later articles]
| List of all articles for this month |

From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 09 Jan 2023 11:24:07 -0800
Organization: None to speak of
References: 23-01-001 23-01-002 23-01-003 23-01-008 23-01-020 23-01-024
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="32833"; mail-complaints-to="abuse@iecc.com"
Keywords: C, history
Posted-Date: 09 Jan 2023 21:37:45 EST

David Brown <david.brown@hesbynett.no> writes:
[...]
>> [In a mutant version of C with nested scopes, I suppose so, but when C compilers
>> ran in 24K bytes, it didn't. -John]
>
> I don't have my copy of K&R handy, or a pre-K&R Unix C manuals, but I
> expect someone will correct me if I'm wrong :-) As far as I know, the C
> described in "The C Programming Language" in 1978, when 24 KB was still
> a big deal, supported declarations at the start of any compound
> statement block. That is, nested scopes. It's possible that pre-K&R C
> compilers were more limited.
> [I actually used that 24K C compiler in about 1975 and I am reasonably sure
> it did not let you put declarations other than in the outer block. There's
> a 1978 edition of K&R at archive.org and by then it did let you put
> declarations in any block. It's a little harder than what you say because
> declarations in non-overlapping blocks should overlay each other, e.g.:
>
> foo() {
> int a:
> ...
> {
> int b[100];
> somefunc(b);
> }
> {
> float c[100];
> otherfunc(c);
> }
> }
>
> you want b and c to use the same storage. It's not hard, but it's a little
> more than promoting and renaming. -John]


The 1975 C reference manual <https://www.bell-labs.com/usr/dmr/www/cman.pdf>
allows declarations at the top of a function body but not at the top of
a compound statement. K&R1 (1978) does allow declarations at the top of
a compound statement.


In the example above, you'd certainly *want* b and c to use the same
storage, but the language doesn't require it. But it's a simple enough
optimization that I'd expect all compilers to do it (or something more
sophisticated). Also, a compiler could either generate code that
allocates storage for each block on entry to the block, or that
allocates the maximum size on entry to the function. I haven't bothered
to look into what compilers actually do. (And it gets more complicated
if you introduce variable-length arrays.)


--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[On a PDP-11 or Vax, adjusting the size of local storage was a single
instruction to adjust the stack pointer at the entry to or exit from
each block. In the example above, imagine that between the two blocks
is a call to bloatfunc() which has a large stack frame and you can see
why it would have been worth it. I will admit that if you had goto
statements, that made it considerably messier. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.