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

David Brown <david.brown@hesbynett.no>
Sun, 8 Jan 2023 20:21:10 +0100

          From comp.compilers

Related articles
[4 earlier articles]
Re: another C-like language? was Compilers :) arnold@skeeve.com (2023-01-04)
Re: another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-04)
Re: another C-like language? was Compilers :) marblypup@yahoo.co.uk (marb...@yahoo.co.uk) (2023-01-05)
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: C scopes, another C-like language? was Compilers :) david.brown@hesbynett.no (David Brown) (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)
[10 later articles]
| List of all articles for this month |

From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.compilers
Date: Sun, 8 Jan 2023 20:21:10 +0100
Organization: A noiseless patient Spider
References: 23-01-001 23-01-002 23-01-003 23-01-008 23-01-020
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="5173"; mail-complaints-to="abuse@iecc.com"
Keywords: C, history, comment
Posted-Date: 08 Jan 2023 17:08:44 EST
Content-Language: en-GB
In-Reply-To: 23-01-020

On 07/01/2023 11:14, marb...@yahoo.co.uk wrote:
>> [If you're doing a one-pass compiler, it's easier if all the declarations are at the
>> beginning so you can generate the code to set up the stack frame and do initializations.
>> I agree that on modern computers it's not a big deal, but remember that early C compilers
>> ran in 24K bytes and I don't mean meagabytes. -John]
>
> Presumably such a compiler would have to create 2 stack frames for
> `char *foo="foo"; puts(foo); { char *bar="bar"; puts(bar); }`


No. The compiler could treat this as though you had written :


char *foo = "foo";
char *bar_nested_scope_1;


puts(foo);
{
bar_nested_scope_1 = "bar";
puts(bar);
}


In other words, it can combine all the variables declared in nested
scope and act as though they were all defined at the start of the
function. It would have to take care of naming, as nested block scopes
could have identifiers that shadow outer scope names. And it may or may
not choose to allow overlapping of variables that have independent
lifetimes.


It only gets complicated when you have variable length arrays, which
would allow the declaration of an array whose size is not known at the
start of the function. But if you are supporting VLA's, you'll already
have support for more sophisticated mixes of variables and code.


> [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]


Post a followup to this message

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