Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.compilers > #3312

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

Show all headers | View raw

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.

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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

csiph-web