Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3270 > unrolled thread

Compilers :)

Back to article view | Back to comp.compilers

Contents

  Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-02 12:28 +0200
    Re: Compilers :) Spiros Bousbouras <spibou@gmail.com> - 2023-01-02 20:52 +0000
      Re: another C-like language? was Compilers :) Steve Limb <stephenjohnlimb@gmail.com> - 2023-01-03 16:24 +0000
        Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-03 12:52 -0800
          Re: another C-like language? was Compilers :) arnold@skeeve.com (Aharon Robbins) - 2023-01-04 17:12 +0000
            Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-04 12:39 -0800
        Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-05 06:27 -0800
          Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-05 16:26 -0800
          Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-06 15:39 +0100
            Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 17:41 +0000
              Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-10 17:48 +0100
                Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-10 15:13 -0800
                  Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-11 13:38 +0100
                    Re: back in the 60s, another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-11 16:38 -0800
                    Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:26 -0800
                Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-11 11:02 +0000
                  Re: Scheme is not another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-12 02:54 -0500
                Re: another C-like language? was Compilers :) Bill Findlay <findlaybill@blueyonder.co.uk> - 2023-01-11 11:58 +0000
              Re: another C-like language? was Compilers :) Thomas Koenig <tkoenig@netcologne.de> - 2023-01-11 10:49 +0000
                Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:21 -0800
                  Re: another C-like language? was Compilers :) Andy Walker <anw@cuboid.co.uk> - 2023-01-15 22:01 +0000
              Re: another C-like language? was Compilers :) "Luke A. Guest" <laguest@archeia.com> - 2023-01-13 18:25 +0000
                Re: another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-13 17:20 -0500
                Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-14 19:07 +0000
          Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-07 02:14 -0800
            Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-08 20:21 +0100
              Re: another C-like language? was Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-09 04:48 +0100
                Re: C scopes, another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-09 18:12 +0100
              Re: another C-like language? was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-09 11:24 -0800
      Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 13:41 +0200
    Re: Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-05 01:12 +0100
      Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 14:17 +0200
        Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 10:32 -0800
          Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 12:39 -0800
            Re: C and Java, was Compilers :) dave_thompson_2@comcast.net - 2023-01-28 10:37 -0500
              Re: C and archtecture, C and Java, was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 19:37 -0800
              Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-29 21:39 -0800

Page 1 of 2  [1] 2  Next page →

#3270 — Compilers :)

I am currently working on my own compiler for something like C but with
minimal object orientation support and no features like
templating/generics etc etc.

Trying to get a feeler out there for anyone who would be interested in
using such a language, obviously the project is something I work on in
my spare time but I have written everything from scratch. I plan to, by
the end of 2023 hopefully, have a full release out. The code emit is
already working well and so is the dependency tree algorithmn.

Also, keen to hear what everyone else is working on here?

[Not to discourage you or anything, but the chances of people
switching to yet another C-like language rounds to zero. Only Rust and
Go have gotten any traction lately, but they both have big companies
behind them, and they have libraries and build environments.  Writing
your own language is fun and a good way to learn, but it's not likely
to be of interest to other people. -John]

[toc] | [next] | [standalone]

#3271

On Mon, 2 Jan 2023 12:28:12 +0200
"Tristan B. Velloza Kildaire" <deavmi@redxen.eu> wrote:
> I am currently working on my own compiler for something like C but with
> minimal object orientation support and no features like
> templating/generics etc etc.
>
> Trying to get a feeler out there for anyone who would be interested in
> using such a language, obviously the project is something I work on in
> my spare time but I have written everything from scratch.

Knowing what you are trying to achieve i.e. why you are creating a new
programming language would be useful. On which operating systems is it
going to work ? What will be the license ?

> I plan to, by
> the end of 2023 hopefully, have a full release out. The code emit is
> already working well and so is the dependency tree algorithmn.

Code emitter for what targets ?

[toc] | [prev] | [next] | [standalone]

#3272 — Re: another C-like language? was Compilers :)

I’m not sure there would be that much demand for a cut down C.

I too am working on a language - https://www.ek9.io/ . I’m not sure that
will get any traction either!

But it is technically challenging and interesting grappling with the
compromises and technologies involved.

My main drive has been to experiment with syntax in different forms and see
how they feel and also
roll in loads (probably an excessive amount) of much higher level concepts.

> On 2 Jan 2023, at 20:52, Spiros Bousbouras <spibou@gmail.com> wrote:
>
> On Mon, 2 Jan 2023 12:28:12 +0200
> "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> wrote:
>> I am currently working on my own compiler for something like C but with
>> minimal object orientation support and no features like
>> templating/generics etc etc.
>>
>> Trying to get a feeler out there for anyone who would be interested in
>> using such a language, obviously the project is something I work on in
>> my spare time but I have written everything from scratch.
>
> Knowing what you are trying to achieve i.e. why you are creating a new
> programming language would be useful. On which operating systems is it
> going to work ? What will be the license ?
>
>> I plan to, by
>> the end of 2023 hopefully, have a full release out. The code emit is
>> already working well and so is the dependency tree algorithmn.
>
> Code emitter for what targets ?

[toc] | [prev] | [next] | [standalone]

#3273 — Re: another C-like language? was Compilers :)

On Tuesday, January 3, 2023 at 9:45:17 AM UTC-8, Steve Limb wrote:
> I’m not sure there would be that much demand for a cut down C.

I was reading it as a cut down C++, or maybe a cut-up C.

If you think that C++ has too many features, then I can see a reduced
version.  Personally, I think that is why I like Java over C++.

Well, for one, it is more C-like than C++.

Otherwise, I believe the source for the original C++ compiler, which
converted to C for a C compiler, is still around, and could be used as
a start for a new C++ like language.

[toc] | [prev] | [next] | [standalone]

#3274 — Re: another C-like language? was Compilers :)

In article <23-01-004@comp.compilers>, gah4  <gah4@u.washington.edu> wrote:
>Otherwise, I believe the source for the original C++ compiler, which
>converted to C for a C compiler, is still around, and could be used as
>a start for a new C++ like language.

This is true that it's around, but I think it has copyright / license
limitations that would prevent building something new on top of it.

Arnold
--
Aharon (Arnold) Robbins 		arnold AT skeeve DOT com

[The copy at the computer history museum says "The source code in this
section is posted with the permission of the copyright owner for
historical research purposes only."  It's from 1997 so I would think
it's a long way from modern C++. -John]

[toc] | [prev] | [next] | [standalone]

#3275 — Re: another C-like language? was Compilers :)

On Wednesday, January 4, 2023 at 10:26:58 AM UTC-8, Aharon Robbins wrote:

(snip, where I wrote about the original C++ compiler.)

> This is true that it's around, but I think it has copyright / license
> limitations that would prevent building something new on top of it.

> [The copy at the computer history museum says "The source code in this
> section is posted with the permission of the copyright owner for
> historical research purposes only." It's from 1997 so I would think
> it's a long way from modern C++. -John]

It sounds like the OP is, so far, in a research project.

But also seems to want something like C++, but without all the
fancy new features.  Starting with a compiler without those features,
seemed like a good way to go.

(I believe some have suggested, over the years, a C--, though
exactly which features are removed, I don't know.)

The process for starting with copyright code, and modifying it
until all copyright parts are gone, seems to be well known, though
I suspect never easy.
[I wouldn't try mutating out the copyrighted stuff.  Depending on how
aggressive the copyright holder is, they can claim copyright in the
structure and sequence of the code.  And if it's a research project,
it's not that hard to make a parser and symbol table using compiler
tools better than 1997 era yacc. -John]

[toc] | [prev] | [next] | [standalone]

#3277 — Re: another C-like language? was Compilers :)

On Tuesday, 3 January 2023 at 17:45:17 UTC, Steve Limb wrote:
> I’m not sure there would be that much demand for a cut down C.

I recently read (well, skimmed)
http://www.mjbauer.biz/C-less%20Reference%20Manual.pdf
"A concise subset of the C programming language".
Though I'm a bit baffled by some of Bauer's choices. Why is
`char *foo="foo", *bar="bar"; puts(foo); puts(bar);`
allowed but not
`char *foo="foo"; puts(foo); char *bar="bar"; puts(bar);`
? Admittedly, the latter is only allowed in relatively recent C, but from my
(very limited) experience writing compilers, the latter is no harder to
compile.
I idly thought about adding stuff to C-less and calling it C-more-or-less,
Cmol, for short.

I'm up for reading the source of any relatively simple compiler for, and
written in, anything C-like. I've tried making sense of the GNU C compiler a
few times. My brain may recover one day!
[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]

[toc] | [prev] | [next] | [standalone]

#3282 — Re: another C-like language? was Compilers :)

On Thursday, January 5, 2023 at 6:34:35 AM UTC-8, marb...@yahoo.co.uk wrote:

(snip)
> I'm up for reading the source of any relatively simple compiler for, and
> written in, anything C-like. I've tried making sense of the GNU C compiler a
> few times. My brain may recover one day!

Some years ago, I bought the LCC book.

The book explains it in some detail, in addition to any comments
in the code.  As well as I know, it is meant for understanding.

It is especially convenient if you only what to retarget the code
generator, for a new (or existing) machine.

I have no desire to look at gcc.

[toc] | [prev] | [next] | [standalone]

#3285 — Re: another C-like language? was Compilers :)

On 05/01/2023 15:27, marb...@yahoo.co.uk wrote:
> On Tuesday, 3 January 2023 at 17:45:17 UTC, Steve Limb wrote:
>> I’m not sure there would be that much demand for a cut down C.
>
> I recently read (well, skimmed)
> http://www.mjbauer.biz/C-less%20Reference%20Manual.pdf
> "A concise subset of the C programming language".
> Though I'm a bit baffled by some of Bauer's choices. Why is
> `char *foo="foo", *bar="bar"; puts(foo); puts(bar);`
> allowed but not
> `char *foo="foo"; puts(foo); char *bar="bar"; puts(bar);`
> ? Admittedly, the latter is only allowed in relatively recent C, but from my
> (very limited) experience writing compilers, the latter is no harder to
> compile.

By "relatively recent C", you mean C99 ?  Mixing statements and
declarations was standardised in C nearly 25 years ago, and was probably
implemented at least a decade before that in some compilers.  (Some C
compilers incorporated features from C++ that later became standardised
in C99.)

> I idly thought about adding stuff to C-less and calling it C-more-or-less,
> Cmol, for short.

There have been many "sort-of-C" languages made, as well as
"sort-of-C++".  (Embedded C++ was one attempt at making a simpler subset
of C++ for use in embedded systems - despite significant backing, it has
failed completely.)

One subset of C that was useful is C--.  This was aimed at being a code
generation target for higher level languages, to improve portability and
save the high level compiler writers from learning the details of
assembly language on different targets.  I think these days it is more
common to target LLVM or a common virtual machine (such as JVM) for such
purposes.


The "C-less" language referenced in the link above seems to be targeting
"a first course in embedded programming".  As an embedded programmer by
profession, I would not want to hire a new developer that had learned
"C-less".  They would /think/ that they could program in C, but be
mislead in several areas and have learned a number of bad habits.  (I
don't want to go through them all, but I agree with you that the style
of "all your declarations at the start of the function" is long
outdated, and often - but not universally - considered a bad idea.)

I also find it strange that this is supposedly a description of parts of
the C language, but regularly uses different terms from the C standards
and other C documentation for no visible benefit.  This could only serve
to confuse the student.


> I'm up for reading the source of any relatively simple compiler for, and
> written in, anything C-like. I've tried making sense of the GNU C compiler a
> few times. My brain may recover one day!

gcc is the result of thousands of man-hours, spread over about 5 decades
and thousands of contributors.  No, it is not an easy read!  I think
"LCC" is probably the best choice of a simple C compiler to read and
understand - this was part of the motivation for writing it.  "Tiny C
Compiler" is another option.


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

If you are writing a compiler for use by people writing code, then being
able to mix declarations and statements is hugely important - and since
generally people /use/ compilers more than they write them, the
trade-off should be on the side of the effort for the users, rather than
the compiler writers.

But if you are writing it for fun, or to learn about compiler writing,
then of course a simpler language is easier.  And if your aim is for an
intermediary language generated by a higher level compiler, then a
simple subset is also convenient.

[toc] | [prev] | [next] | [standalone]

#3297 — Re: another C-like language? was Compilers :)

On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
> don't want to go through them all, but I agree with you that the style
> of "all your declarations at the start of the function" is long
> outdated, and often - but not universally - considered a bad idea.)

Declarations have never been required to be at the top of a function in
C, because they can be in any compound statement block. I think
that goes all the way back to the B language. [Nope, see the next message. -John]

The "Variables at the top" meme may be something coming from Pascal.
IIRC, in Pascal, compound statements aren't full blocks; they cannot
have VAR declarations.

When programmers abandoned Pascal in the 1980s, they carried over this
habit into C.

I hate mixed declarations and code because it's almost sa bad as
variables-at-the-top. The scope of a declaration that is just planted
into the middle of a compound statement block extends all the way to the
end of the block. There should be a smaller enclosing block which
exactly delimits the scope of that variable.  If some variable is used
over seven lines of a 300 line function, those seven lines should
ideally be enclosed in curly braces, so the variable is not known
outside of those lines. Just planting an unwrapped declaration of the
variable at the function scope level (outermost block) solves only half
the problem. The scope of the variable starts close to where the
variable is used, which is good; but it still goes to the end of the
function, way past its actual semantic scope that ends at the last use.

A block like this can be repeated with copy and paste:

 {
   int yes = 1;
   setsockopt(fd, SO_WHATEVER, &yes);
 }

This cannot: you will get redefinition errors:

 int yes = 1;
 setsockopt(fd, SO_WHATEVER, &yes);

you have to think about ensuring that "int yes" occurs in one place
that is before the first use, and the other places assign to it.
Or invent different names.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#3301 — Re: another C-like language? was Compilers :)

On 09/01/2023 18:41, Kaz Kylheku wrote:
> On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
>> don't want to go through them all, but I agree with you that the style
>> of "all your declarations at the start of the function" is long
>> outdated, and often - but not universally - considered a bad idea.)
>
> Declarations have never been required to be at the top of a function in
> C, because they can be in any compound statement block. I think
> that goes all the way back to the B language. [Nope, see the next message. -John]
>
> The "Variables at the top" meme may be something coming from Pascal.
> IIRC, in Pascal, compound statements aren't full blocks; they cannot
> have VAR declarations.

I suspect it is much older than that - in assembly programming, you do
not normally mix data and code sections.

> When programmers abandoned Pascal in the 1980s, they carried over this
> habit into C.
>
> I hate mixed declarations and code because it's almost as bad as
> variables-at-the-top. The scope of a declaration that is just planted
> into the middle of a compound statement block extends all the way to the
> end of the block. There should be a smaller enclosing block which
> exactly delimits the scope of that variable.  If some variable is used
> over seven lines of a 300 line function, those seven lines should
> ideally be enclosed in curly braces, so the variable is not known
> outside of those lines. Just planting an unwrapped declaration of the
> variable at the function scope level (outermost block) solves only half
> the problem. The scope of the variable starts close to where the
> variable is used, which is good; but it still goes to the end of the
> function, way past its actual semantic scope that ends at the last use.

If your variable is only used in 7 lines out of a 300 line function,
then perhaps your function is too long?

I agree that small scopes for variables are good, and put declarations
within compound statement blocks where practical (though I rarely make a
new block simply to hold a variable).  But that is not the sole purpose
of mixing code and declarations - it is not even the major purpose, IMHO.

The point is that you do not declare a variable until you actually have
something to put in it.  You never have this semi-alive object floating
around where it is accessible, but has no valid or known state.  You
never have an artificial initialisation, such as putting 0 in a variable
declared at the top of the function, in the mistaken believe that it
makes code somehow "safer".  You can make your variables "const" if they
do not change.  If you are using C++ (or other object-oriented
language), you avoid the inefficiency of default-constructing an object
and later assigning to it, instead of doing a single initialisation.

Of course this applies just as well to variables defined inside blocks
as to variables defined after code.

> A block like this can be repeated with copy and paste:
>
>   {
>     int yes = 1;
>     setsockopt(fd, SO_WHATEVER, &yes);
>   }
>
> This cannot: you will get redefinition errors:
>
>   int yes = 1;
>   setsockopt(fd, SO_WHATEVER, &yes);
>
> you have to think about ensuring that "int yes" occurs in one place
> that is before the first use, and the other places assign to it.
> Or invent different names.
>

This is something that I would prefer C and C++ to allow.  I think it
would improve the structure of some of my code, precisely as you describe.

I'd also like to be able to write :

	int x = 10;
	x += 20;
	const int x = x;	// Fix x - after this, x is constant

I wonder if anyone has made a proposal for adding this feature to C or C++ ?
[Variables at the top probably comes from Algol60 via Pascal.  For assembler,
depends on the assembler.  Lots of them let you have several sections in the
program and switch between the code and data sections as you go.  IBM mainframe
assemblers had this feature in the 1960s. -John]

[toc] | [prev] | [next] | [standalone]

#3302 — Re: another C-like language? was Compilers :)

On Tuesday, January 10, 2023 at 2:16:32 PM UTC-8, David Brown wrote:

(snip)
> The point is that you do not declare a variable until you actually have
> something to put in it. You never have this semi-alive object floating
> around where it is accessible, but has no valid or known state. You
> never have an artificial initialisation, such as putting 0 in a variable
> declared at the top of the function, in the mistaken believe that it
> makes code somehow "safer".

Java requires that the compiler be able to figure out that a variable
(well, scalar variable) is given a value before it is used.  Most of the
time, that works out fine.  Once in a while, I know that it is given
a value, but the compiler doesn't.   In that case, it is initialized
to (usually) 0, and a comment indicating why.

(snip)

> [Variables at the top probably comes from Algol60 via Pascal. For assembler,
> depends on the assembler. Lots of them let you have several sections in the
> program and switch between the code and data sections as you go. IBM mainframe
> assemblers had this feature in the 1960s. -John]

Most of the IBM mainframe assembly code I know, puts the variables
at the bottom.

Well, early on I started reading the generated code from compilers,
and not so much later, the Fortran G&H library.  Maybe not the best
examples of structured code, though.

Well, if by data section you mean DSECT, I suppose.
Most I knew didn't do much of that, though.

Variables at the bottom, and use the same base register for
code and data.  You could put the variables at the top, and
branch around them.  I don't remember anyone doing that.

More recent processors, maybe from ESA/390 days, have
data and instruction cache, and want data and instructions
more than (if I remember) 256 bytes apart.

But okay, it is completely different for reentrant programs,
than the static allocation non-reentrant code of much of
OS/360 associated programs.
[For IBM assember, I meant that you could have one CSECT for
your code and another for your data, and you could switch
between them as you go along.  For the elite few of us who
used TSS/360, a PSECT let you set the initial contents of
the RW data that the RO code in a routine used.  DSECT was
somehing else, more like a structure definition. I realize
that in practice most code was not reentrant and you put
all your code and data in one section. -John]

[toc] | [prev] | [next] | [standalone]

#3308 — Re: another C-like language? was Compilers :)

On 11/01/2023 00:13, gah4 wrote:
> On Tuesday, January 10, 2023 at 2:16:32 PM UTC-8, David Brown wrote:
>
> (snip)
>> The point is that you do not declare a variable until you actually have
>> something to put in it. You never have this semi-alive object floating
>> around where it is accessible, but has no valid or known state. You
>> never have an artificial initialisation, such as putting 0 in a variable
>> declared at the top of the function, in the mistaken believe that it
>> makes code somehow "safer".
>
> Java requires that the compiler be able to figure out that a variable
> (well, scalar variable) is given a value before it is used.  Most of the
> time, that works out fine.  Once in a while, I know that it is given
> a value, but the compiler doesn't.   In that case, it is initialized
> to (usually) 0, and a comment indicating why.
>

The same applies to C and C++ programming, when using static error
checking.  (And during development, you should definitely be using a
compiler capable of spotting missing initialisations, and you should
treat such warnings as bugs in your code.)  And like Java tools, C and
C++ compilers are not /quite/ perfect :-)

So I agree that there are occasional uses for such "artificial"
initialisation.  There are also occasions when declaring a variable
without initialising makes sense because you will later set its value
inside a conditional.

But in general, declaring and initialising at the same time is better
(IMHO).  And artificial zero initialisation is a bad thing, precisely
because it effectively disables the kind of warning checks you get in
Java and in C/C++ with an appropriate compiler or linter.

> (snip)
>
>> [Variables at the top probably comes from Algol60 via Pascal. For assembler,
>> depends on the assembler. Lots of them let you have several sections in the
>> program and switch between the code and data sections as you go. IBM mainframe
>> assemblers had this feature in the 1960s. -John]
>
> Most of the IBM mainframe assembly code I know, puts the variables
> at the bottom.

That's new to me - but I have no experience with mainframes.  In all the
assembly I have done (lots of different microcontrollers), I have always
had the data declared before the code that uses them.  I've alternated
between data and code sections, but not within functions.

But maybe this is because most of the small microcontrollers I
programmed were pretty hopeless at dealing with data on a stack, and it
was normal to put local variables in data sections - you have static
addressing, rather than through base pointers or frame pointers.  It is
quite different from how you work with "big" processors - even in the
days when the "big" processors were slower and had less memory than
modern "small" processors, if you understand what I mean.

Thanks for the history titbits here.  It's always fun to hear about.

[toc] | [prev] | [next] | [standalone]

#3312 — Re: back in the 60s, another C-like language? was Compilers :)

On Wednesday, January 11, 2023 at 3:10:38 PM UTC-8, David Brown wrote:

(snip, I wrote)
> > Java requires that the compiler be able to figure out that a variable
> > (well, scalar variable) is given a value before it is used.

(snip)
> The same applies to C and C++ programming, when using static error
> checking. (And during development, you should definitely be using a
> compiler capable of spotting missing initialisations, and you should
> treat such warnings as bugs in your code.) And like Java tools, C and
> C++ compilers are not /quite/ perfect :-)

As well as I know it, this isn't optional in Java.

> So I agree that there are occasional uses for such "artificial"
> initialisation. There are also occasions when declaring a variable
> without initialising makes sense because you will later set its value
> inside a conditional.

(snip)
> >> [Variables at the top probably comes from Algol60 via Pascal. For assembler,
> >> depends on the assembler. Lots of them let you have several sections in the
> >> program and switch between the code and data sections as you go. IBM mainframe
> >> assemblers had this feature in the 1960s. -John]

I remember knowing that, but rarely seeing it.  In high school years, I would
read IBM manuals, and so knew many things that I would never use.

And since each card of the object program has its address, and which CSECT
it belongs to, the linker can figure it all out.

> > Most of the IBM mainframe assembly code I know, puts the variables
> > at the bottom.

> That's new to me - but I have no experience with mainframes. In all the
> assembly I have done (lots of different microcontrollers), I have always
> had the data declared before the code that uses them. I've alternated
> between data and code sections, but not within functions.

If you allow forward references for code (that is, forward jumps),
you can also have forward references for data.

Well, this all works if you have (at least) a two pass assembler.
Find the address of everything the first time through, and then
generate code on the second pass.

> But maybe this is because most of the small microcontrollers I
> programmed were pretty hopeless at dealing with data on a stack, and it
> was normal to put local variables in data sections - you have static
> addressing, rather than through base pointers or frame pointers. It is
> quite different from how you work with "big" processors - even in the
> days when the "big" processors were slower and had less memory than
> modern "small" processors, if you understand what I mean.

I am now remembering that the early IBM Fortran compilers put code
at the bottom of address space, and data at the top, going down.

One early Fortran feature that got removed later, is the ability to chain.
One (whole) program can chain to another, which then replaces it
in memory, but  with all COMMON variables still there.

I suspect that this was replaced by overlay, which is a better
solution to the problem.  It might be that, which led to putting
data after code.

Another one is that with base-displacement addressing, you only
need to be able to address the beginning of an array.  Putting large
arrays at the end, then, makes it easier.

That is also the way Fortran code generators did it for OS/360.
(Static addressed with code and data together.)

Early microcomputer assemblers might not have been as good,
though as well as I know it, Microsoft used the PDP-10 assembler
from the beginning.

A favorite way to write microcomputer assembly code, is with
macros on a mainframe assembler, one for each instruction.
All the hard work is then done by the assembler itself.

[toc] | [prev] | [next] | [standalone]

#3328 — Re: another C-like language? was Compilers :)

On Wednesday, 11 January 2023 at 23:10:38 UTC, David Brown wrote:
> The same applies to C and C++ programming, when using static error
> checking. (And during development, you should definitely be using a
> compiler capable of spotting missing initialisations, and you should
> treat such warnings as bugs in your code.) And like Java tools, C and
> C++ compilers are not /quite/ perfect :-)
>
> So I agree that there are occasional uses for such "artificial"
> initialisation. There are also occasions when declaring a variable
> without initialising makes sense because you will later set its value
> inside a conditional.

Indeed. I've occasionally had compilers complain about uninitialised
variables though I could see that my (rather perverse?) code did
always initialise them before they were used (but possibly not if they
weren't). In such cases, I've added an initialisation to the
declaration just to shut the compiler up. (Warnings of uninitialised
variables usually do indicate bugs.)

[toc] | [prev] | [next] | [standalone]

#3306 — Re: another C-like language? was Compilers :)

On 2023-01-10, David Brown <david.brown@hesbynett.no> wrote:
> On 09/01/2023 18:41, Kaz Kylheku wrote:
>> On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
>> A block like this can be repeated with copy and paste:
>>
>>   {
>>     int yes = 1;
>>     setsockopt(fd, SO_WHATEVER, &yes);
>>   }
>>
>> This cannot: you will get redefinition errors:
>>
>>   int yes = 1;
>>   setsockopt(fd, SO_WHATEVER, &yes);
>>
>> you have to think about ensuring that "int yes" occurs in one place
>> that is before the first use, and the other places assign to it.
>> Or invent different names.
>
> This is something that I would prefer C and C++ to allow.  I think it
> would improve the structure of some of my code, precisely as you describe.

It seems that Scheme, with its ugly (define ...) that can be used inside
block scopes, has the same restriction!

I tried (lambda () (define x 42) (define x 43)) in a Scheme
implementation and got an error about the duplicate variable.

That's completely silly since it breaks the idea that the block scoped
define can just be desugared to nested lets.

On a related topic, the CLISP implementation of Common Lisp, whose
history goes back to the 1980s, availed itself of mixing variable
declarations and statements even in C90. Its source files are named with
a .d suffix, and are preproced by a "varbrace" tool which spits out
the brace-enclosed blocks. I seem to recall that variables are prefixed
with a "var" specifier, which probably makes it easy for the tool to
recognize declarations.

It may likely be the case that under CLISP's "varbrace" you can repeat
variable names.

... and searching for varbrace, I see a 2017 thread in the CLISP
mailing list by someone who posted a patch to rid CLISP of varbrace,
and just use C99.  The patch submmitter mentions that he had to rename
some instances of repeated variables, making this remark:

   Another issue is conflicting definitions of the same variable. Example:

    var type1 foo;
    // some code
    var type2 foo;

  This is solved by renaming one of them, if possible. In two places, I
  manually added braces (like varbrace would've done)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#3314 — Re: Scheme is not another C-like language? was Compilers :)

On Wed, 11 Jan 2023 11:02:56 -0000 (UTC), Kaz Kylheku
<864-117-4973@kylheku.com> wrote:


>It seems that Scheme, with its ugly (define ...) that can be used inside
>block scopes, [disallows name redefinition]!

Agree it's ugly: I never use internal defines in my own code.
Unfortunately some people love them.


>I tried (lambda () (define x 42) (define x 43)) in a Scheme
>implementation and got an error about the duplicate variable.
>
>That's completely silly since it breaks the idea that the block scoped
>define can just be desugared to nested lets.


Unfortunately the experience varies by version:


From R3RS to R5RS, a series of internal defines is treated AS IF they
all are part of a single 'letrec' with the scope being the whole body.
'letrec', of course, does not permit multiple bindings to the same
name.

In R6RS and R7RS, a series of internal defines is treated as a
'letrec*' [note trailing *].  letrec* is equivalent to nested letrec
and so does permit rebinding to the same name ... which will shadow
any previous bindings.



from  R5RS 5.2.2 Internal Definitions

... The variable defined by an internal defnition is local to the
body. That is, variable is bound rather than assigned, and the region
of the binding is the entire body. For example,

  (let ((x 5))
    (define foo (lambda (y) (bar x y)))
    (define bar (lambda (a b) (+ (* a b) a)))
    (foo (+ x 3))) => 45

A body containing internal definitions can always be converted into a
completely equivalent letrec expression. For example, the let
expression in the above example is equivalent to

   (let ((x 5))
     (letrec ((foo (lambda (y) (bar x y)))
              (bar (lambda (a b) (+ (* a b) a))))
       (foo (+ x 3))))

Just as for the equivalent letrec expression, it must be possible to
evaluate each expression of every internal definition in a body
without assigning or referring to the value of any variable being
defined.



From  R6RS 11.3 Bodies

The <body> of a lambda, let, let*, let-values, let*-values, letrec, or
letrec* expression, or that of a definition with a body consists of
zero or more definitions followed by one or more expressions.

<definition> ... <expression1> <expression2> ...

Each identifier defined by a definition is local to the <body>. That
is, the identifier is bound, and the region of the binding is the
entire <body> (see section [5.2]).

Example:

(let ((x 5))
  (define foo (lambda (y) (bar x y)))
  (define bar (lambda (a b) (+ (* a b) a)))
  (foo (+ x 3)))               =>  45

When begin, let-syntax, or letrec-syntax forms occur in a body prior
to the first expression, they are spliced into the body; see
section [11.4.7]. Some or all of the body, including portions wrapped
in begin, let-syntax, or letrec-syntax forms, may be specified by a
macro use (see section [9.2]).

An expanded <body> (see chapter [10]) containing variable definitions
can always be converted into an equivalent letrec* expression. For
example, the let expression in the above example is equivalent to

(let ((x 5))
  (letrec* ((foo (lambda (y) (bar x y)))
            (bar (lambda (a b) (+ (\* a b) a))))
    (foo (+ x 3))))

[toc] | [prev] | [next] | [standalone]

#3307 — Re: another C-like language? was Compilers :)

On 10 Jan 2023, David Brown wrote
(in article <23-01-033@comp.compilers>):

> [Variables at the top probably comes from Algol60 via Pascal. ... -John]

And via Algol 60 from FORTRAN.

--
Bill Findlay

[toc] | [prev] | [next] | [standalone]

#3305 — Re: another C-like language? was Compilers :)

Kaz Kylheku <864-117-4973@kylheku.com> schrieb:

> The "Variables at the top" meme may be something coming from Pascal.
> IIRC, in Pascal, compound statements aren't full blocks; they cannot
> have VAR declarations.

FORTRAN has had declaration statements (first version, DIMENSION
only) at the top of procedures since the beginning.  Algol 58
aka IAL had declarations everywere, while Algol 60 allowed them
only at the beginning of blocks.

> When programmers abandoned Pascal in the 1980s, they carried over this
> habit into C.

Probably, C just carried it over from the Algol tradition.

[toc] | [prev] | [next] | [standalone]

#3327 — Re: another C-like language? was Compilers :)

On Wednesday, 11 January 2023 at 23:07:33 UTC, Thomas Koenig wrote:
> Algol 58
> aka IAL had declarations everywere, while Algol 60 allowed them
> only at the beginning of blocks.

But Algol 68 allows them anywhere:

INT x:=42;
print(("x=",x,newline));
INT y:=76;
print(("y=",y,newline));
x:=y:=101;
print(("x=",x,newline,"y=",y,newline))

(There's something a bit weird about it in A68, though, but I can't remember what.)
(I tend to think of A68 as "A60 made perfect... then some dubious
features are added". I gather it took 6 years to write the first
complete A68 compiler! Well, strictly speaking, they'd revised A68 by
then, so it was an A68R compiler.)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.compilers

csiph-web