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

gah4 <gah4@u.washington.edu>
Wed, 11 Jan 2023 16:38:32 -0800 (PST)

          From comp.compilers

Related articles
[3 earlier articles]
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 :) david.brown@hesbynett.no (David Brown) (2023-01-06)
Re: another C-like language? was Compilers :) 864-117-4973@kylheku.com (Kaz Kylheku) (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 :) david.brown@hesbynett.no (David Brown) (2023-01-11)
Re: back in the 60s, another C-like language? was Compilers :) gah4@u.washington.edu (gah4) (2023-01-11)
| List of all articles for this month |
From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Wed, 11 Jan 2023 16:38:32 -0800 (PST)
Organization: Compilers Central
References: 23-01-001 23-01-002 23-01-003 23-01-008 23-01-016 23-01-029 23-01-033 23-01-034 23-01-040
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="35532"; mail-complaints-to="abuse@iecc.com"
Keywords: code, history
Posted-Date: 11 Jan 2023 22:25:48 EST
In-Reply-To: 23-01-040

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.


Post a followup to this message

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