That darn Bug story
Don Stokes
> as an error. Many Pascal compilers were designed to accept the empty
> statement to make it easier on the programmer.
I didn't think that making things easier for the programmer was one of the
design goals for Pascal.
--
Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand +64-4-495-5052
Charles Lasner
>de...@bcarh823.BNR.CA (Dean Dillabough) writes:
>> as an error. Many Pascal compilers were designed to accept the empty
>> statement to make it easier on the programmer.
>
>I didn't think that making things easier for the programmer was one of the
>design goals for Pascal.
It's grotesquely obvious that it was designed to be done in one pass, to
make it easier on the programmer WHO WROTE THE COMPILER.
cjl
Dik T. Winter
to do with the ease of the programmer of the compiler (Urs Amman, ETH,
who did it as his Ph.D. thesis, and a very good compiler it was with
proper error recovery %). The null statement is an inheritance of Algol-60.
And Algol-60 had the null statement to enable you to put a label just
before the end of a compound statement or of a block statement.
--
% Yes, really one pass. As soon as a statement was seen the object code was
emitted. No assembler needed or some such nonsense. But this was of
course on the CDC Cyber series that had an extremely fast and excellent
linking loader. What other systems are there where you would keep your
binaries in unlinked relocatable form because you did not notice that
linking was also done in the load step (including linking against
libraries)? (Do not yell Cray, because the loader under COS was functionally
the same as the Cyber loader.) The CDC Pascal compiler (all versions based
on Urs Amman's compiler) generated a separate object module for each
function/procedure. Linking those, adjustment of addresses of labels and
of global variables all were done by the linking loader. Although the
loader had the option to generate an absolute, pre-linked binary from
the objects and libraries, nearly nobody did that, because the difference
was could not be noticed. (And that with the equivalent of 180 kB of
memory for interactive use.) When I first did use Unix on a Vax (BSD on
a 780) I was apalled at the slowness of the linking process. And still am
in fact.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: d...@cwi.nl
Charles Lasner
>In article <1992Sep25....@news.columbia.edu> las...@watsun.cc.columbia.edu (Charles Lasner) writes:
> > In article <498...@zl2tnm.gen.nz> d...@zl2tnm.gen.nz (Don Stokes) writes:
> > >de...@bcarh823.BNR.CA (Dean Dillabough) writes:
> > >> as an error. Many Pascal compilers were designed to accept the empty
> > >> statement to make it easier on the programmer.
> > >
> > >I didn't think that making things easier for the programmer was one of the
> > >design goals for Pascal.
> >
> > It's grotesquely obvious that it was designed to be done in one pass, to
> > make it easier on the programmer WHO WROTE THE COMPILER.
> >
>This is a wrong representation of course. The null statement has nothing
>to do with the ease of the programmer of the compiler (Urs Amman, ETH,
I was addressing the statement, not the specific remark about null statements,
but the statement about the goals of the language in general, i.e., that it
sacrifices certain alternative features, such as FORWARD being unnecessary, to
allow a one-pass compiler. This was one of my early arguments against certain
hll's, and also certain assemblers. Are languages designed to help programmers
or is it the other way around? If a language is designed for ease of
implementation, not use, then the only programmer who benefits is the
compiler writer.
cjl
Peter da Silva
> the objects and libraries, nearly nobody did that, because the difference
> was could not be noticed. (And that with the equivalent of 180 kB of
> memory for interactive use.) When I first did use Unix on a Vax (BSD on
> a 780) I was apalled at the slowness of the linking process. And still am
> in fact.
Boy, whatta wimp. You should have tried TKB on RSX-11. On the same machine
where an overlaid program linked in 20-30 seconds under UNIX, a simple
"hello world" program took minutes. TKB provided so many linking and loading
options, including function-by-function specification of overlays, that it's
in the running with the OS/360 linker for complexity... but boy was it SLOW!
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' "Have you hugged your wolf today?"
'U`
Sam Wilson
> course on the CDC Cyber series that had an extremely fast and excellent
> linking loader. What other systems are there where you would keep your
> binaries in unlinked relocatable form because you did not notice that
> linking was also done in the load step (including linking against
> libraries)?
Edinburgh's EMAS (1972 - 1992, R.I.P.) did something like this. All
references were indirect via a table built at load-and-run time. This
made all code inherently sharable with no statically linked library
routines. The loader didn't modify code it just searched libraries and
filled in entries in tables.
EMAS also had a wonderful VM system - there was no paging or swapping
area because all file access was memory mapped (and all memory except
that for low level resident stuff was allocated file space). The
combination of that and the first point meant that there was only ever
one copy of any program or library routine in memory at once unless
people did bizarre things to statically link code. That of course made
it exceedingly efficient at using memory and providing a timesharing
service. Unfortunately, since it was unique and not Unix it had to go.
:-(
Oh, yes, and it was almost entirely written in a high level,
Algol-60-like language called IMP. During its life it ran on IBM
360/370 type architecture (English Electric, later ICL 4/75, which was
really an RCA Spectra, I gather), ICL 2900 (completely different,
dedicated register machine) and back on IBM 370/3090 (Amdahl 470 and NAS
VL/80 which later became the HDS EX40, I think).
Compared to all the languages I've seen discussed recently IMP seems to
suffer from the problems of almost none of them with the exception of
being a little verbose to type. I could have dome with more, possibly
extensible data types (one of the things I really started to like in
Pascal until I discovered the hassles you had to go through to output,
say, the value of an enumerated type) - it had various integers and
reals, pointer types and records and proper strings. The best thing
that I've never seen anywhere else was the 'string resolution operator'
- you could say
fred -> joe.(".").bert
which if fred started out as "first.rest.last" would put "first" in joe
and "rest.last" in bert. That looks slightly trivial but you could also
use it in loops and conditionals
%while fred -> (" ").fred %cycle; %repeat
(note the null statement)
%if fred -> junk1.("ERROR").junk2 %then %start
printstring ("Whoops!)
%finish %else %start
printstring ("OK")
%finish
which made for some really nice constructs.
And if anyone tries to start a flame war about the % signs or other 'but
I could do that better in C/assembler/Modula-2/PL/1' I will simply not reply.
> ... When I first did use Unix on a Vax (BSD on
> a 780) I was apalled at the slowness of the linking process. And still am
> in fact.
I get appalled at the size of binaries on Unix and all those duplicated
copies of printf that lie around clogging up disks and memory! EMAS had
shared libraries in 1972...
Sam
Magnus Olsson
^
Is this node named after the Edinburgh Festival?
>Compared to all the languages I've seen discussed recently IMP seems to
>suffer from the problems of almost none of them with the exception of
>being a little verbose to type.
[ Interesting description of some features deleted ]
This sounds interesting - could you possibly post some more details
about this language? And what do you think where the reasons for its
not sufering from the problems of other languages?
Magnus Olsson | \e+ /_
Dept. of Theoretical Physics | \ Z / q
University of Lund, Sweden | >----<
Internet: mag...@thep.lu.se | / \===== g
Bitnet: THEPMO@SELDC52 | /e- \q
Peter da Silva
> Edinburgh's EMAS (1972 - 1992, R.I.P.) did something like this. All
> references were indirect via a table built at load-and-run time.
Oh, while I'm sitting here: the Amiga dynamically links all binaries on
loading. That way they all share a common address space. It doesn't do
dynamic linking for libraries, though, since they're opened explicitly at
run-time and may be flushed from memory if nobody happens to have them
open at a particular time.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
`-_-' "Segodnja volka obnimal?"
'U`
Sam Wilson
> In article <26...@castle.ed.ac.uk> erc...@festival.ed.ac.uk (Sam Wilson) writes:
> > Edinburgh's EMAS (1972 - 1992, R.I.P.) did something like this. All
> > references were indirect via a table built at load-and-run time.
>
> Oh, while I'm sitting here: the Amiga dynamically links all binaries on
> loading. That way they all share a common address space.
On EMAS it was partly because shared code DIDN'T run in the same address
space - ecah logged in user (not program!) had his or her own VM and
shared code had to execute at different addresses in different VMs. The
code was shared but ecah user had an unshared linkage area with the
relocated addresses in.
> ... It doesn't do
> dynamic linking for libraries, though, since they're opened explicitly at
> run-time and may be flushed from memory if nobody happens to have them
> open at a particular time.
Garbage collection, eh? Being a big, grown up system with paging and VM
(despite the original EMAS running 40 simultaneous interactive users on
a machine with 1Mb of main store - hardly 'grown up' these days) EMAS
just used to page over unused stuff, of course.
Oh, one thing I didn't mention before was the extraordinary efficiency
of the memory mapped filing system for file i/o. Whilst one could
emulate character or record or block i/o doing that actually slowed your
program down. The efficient way was just to read consecutive memory
locations and let the paging system bring the file into memory as
necessary.
Sam
Sam Wilson
> "The IMP Language and Compiler", P.D.Stephens, Computer Journal
> vol 17 no 3 p216
Just to raise a hackle or two and cross threads I'll type in a paragraph
from that article, from a section headed "On systme programming in IMP".
This is from 1974 remember.
"The EMAS programmers who had previous experience of high-level
languages adapted easily to system programming in IMP. They
produced compact, highly structured programs which were easy to
maintain or amend despite defects in commentary and/or
documentation. They seldom worried about the efficiency of object
code produced by the compiler, but their programs generally
performed well. This group included the most productive programmers
working on the project. Programmers with a background of assembly
languages were less happy with IMP and seldom used its more advanced
features such as recursion. They produced well commented and
documented programs that nevertheless proved difficult to maintain
since they lacked structure. This group worried about the
efficiency of object code produced by the compiler to the extent of
examining the listings of code produced, yet their programs were
often large in size and slow in execution. Some of the least
productive programmers were included in this group."
Sam
Sam Wilson
> In article <26...@castle.ed.ac.uk> erc...@festival.ed.ac.uk writes:
> ^
> Is this node named after the Edinburgh Festival?
Yep. You'll be aware that in the UK we name our machines forwards (the
rest of the world names them backwards, of course!) and we also have two
forms of name, so what you see as festival.ed.ac.uk we tend to think of
as uk.ac.edinburgh.festival. We also have uk.ac.edinburgh.castle,
uk.ac.edinburgh.rock (a kind of sweet) and uk.ac.edinburgh.fringe (the
less highbrow Festival that goes on around the official one). We don't
yet have uk.ac.edinburgh.crystal (an ornamental glass factory) nor
uk.ac.edinburgh.district.council...
> >Compared to all the languages I've seen discussed recently IMP seems to
> >suffer from the problems of almost none of them with the exception of
> >being a little verbose to type.
>
> [ Interesting description of some features deleted ]
>
> This sounds interesting - could you possibly post some more details
> about this language?
Shame I can't type in the manual! There was a description (part of a
series about EMAS and its development) in the Computer Journal in around
1974 ("The IMP Language and Compiler", P.D.Stephens, Computer Journal
vol 17 no 3 p216). The language was initially designed in about 1966
based on Atlas Autocode, the languace of the Manchester Atlas machine
which was itself derived from Algol 60. It was further developed and
several things were changed in the final version, IMP80: the form of the
counted cycle changed; the until clause of a conditional cycle moved to
the end of the loop (there is a while clause which can be placed at the
beginning); the syntax of record declarations changed; a nested
contingency handling feature introduced; numerical constants in
arbitrary bases were introduced; the string delimiter was changed from '
to " to allow easier distinction between a single character constant (an
integer type), say 'A' and string constants, say "A", which were
actually a structured type with a length byte; an so on and so on.
> ... And what do you think where the reasons for its
> not sufering from the problems of other languages?
By 'reasons' do you mean design criteria or features? On the design
criteria front the designers made sensible choices that balanced the
need to be able to do almost anything with creating a readable,
maintainable language. They specificially excluded features that would
be inefficient or difficult to implement on a range of different
architectures and eschewed cryptic abbreviations in favour of readable
things (for instance the effects of many of C's operators are achieved
with what in IMP are syntactically functions - the address of a variable
is taken with ADDR(variable-name); mapping a variable onto an address is
done with a mapping function, say INTEGER(address).) They did however
allow assembler at any point in a program with access to IMP variables.
The sort of features I had in mind were nested procedure decalations,
separate compilation, the address and mapping functions referred to
above which allow the kind of thing everyone says C is so good at
without the cryptic syntax and byzantine precedence rules (and ensuring
that the built in assembler was hardly ever used).
I used to use it as an applications programmer, but when I ended up
having to more system-y things, particularly on micros, I pined for IMP!
That and the diagnostics - by default (you could turn it off, of course)
you used to get a complete symbolic dump of the stack with all called
routines and the values of all instances of variables at the time of an
error. At one time one of the guys here produced an IMP debugger, but
considering how good the diagnostics were hardly anyone used it. It was
one of the things that didn't get moved when we went to the third
architecture.
Pete Stephens an Geoff Milard left the University some years ago to set
us as a compiler company, Edinburgh Portable Compilers. They still use
IMP as the implementation language for their compilers, I believe, but
only bootstrap enough of it to compile compilers, not necessarily any
more. In it's life IMP or a significant subset of it has run on (at
least) KDF9, IBM 360/370, ICL 4/75, ICL 2900, PDP8, PDP9, PDP11, PDP15,
Modular 1, Univac 1108, IBM 3090-style, Sequent Symmetry (i386/i486) and
no doubt many others hat I don't know about - I'm by no means an expert
in these things.
Sam
Peter David THOMPSON
Pardon?
The Amiga does *relocation* at load time. The default on all C compilers
that I'm aware of is for static linking. DICE supports dynamic linking
via a shared runtime library called dynamic.library, but I'm not aware
of any similar facilities in any other compiler (I can't afford any other
compiler).
The Amiga (or to be more precise, the standard operating system for the
Amiga) also relocates libraries on opening.
If this is a new feature of Kickstart 3.0, it seems to be a good reason
for an upgrade..
* These opinions belong to p...@mundil.cs.mu.OZ.AU unless otherwise specified.
Perform Random Postings And Senseless Acts Of .signature.
Peter da Silva
> several things were changed in the final version, IMP80: the form of the
> counted cycle changed; the until clause of a conditional cycle moved to
> the end of the loop (there is a while clause which can be placed at the
> beginning);
That's nice, much better than the three loops in C.
> arbitrary bases were introduced; the string delimiter was changed from '
> to " to allow easier distinction between a single character constant (an
> integer type), say 'A' and string constants, say "A", which were
That sounds like it influenced or was influenced by C.
> things (for instance the effects of many of C's operators are achieved
> with what in IMP are syntactically functions - the address of a variable
> is taken with ADDR(variable-name); mapping a variable onto an address is
> done with a mapping function, say INTEGER(address).)
Does this mean pointers are untyped? PL/M does this, and it's a big pain.
The typed pointers in C or Pascal are much better.
--
Peter da Silva. <pe...@sugar.neosoft.com>.
Sam Wilson
> > arbitrary bases were introduced; the string delimiter was changed from '
> > to " to allow easier distinction between a single character constant (an
> > integer type), say 'A' and string constants, say "A", which were
>
> That sounds like it influenced or was influenced by C.
I suspect it was parallel evolution - that change happened in about 1978
or 79, I think.
> > things (for instance the effects of many of C's operators are achieved
> > with what in IMP are syntactically functions - the address of a variable
> > is taken with ADDR(variable-name); mapping a variable onto an address is
> > done with a mapping function, say INTEGER(address).)
>
> Does this mean pointers are untyped? PL/M does this, and it's a big pain.
> The typed pointers in C or Pascal are much better.
No, pointers are typed, though addresses are integers rather than a
separated address type. You can of course map a typed pointer to any
address, or the address of a different variable. For example:
%integer i, j
%byte %integer %array b(0:3)
i = 16_12345678; ! base 16 number
b(3-j) = byteinteger(addr(i)+j) %for j = 0,1,3
! extract the bytes from i and put them in b,
! reversing the order using the one-line counted loop
! assumes 4-byte integer, but could be written with
! the 'sizeof' function
or this
%integer i
%byte %integer %array %name b
%byte %integer %array %format fourbyte(0:3)
b == array(addr(i), fourbyte)
! maps b onto the 4 bytes of i, starting at i's
! address and using the format defined above
! == is the mapping operator
As I say, verbose. It also shows its age in the relative paucity of
types available. It would have been nice to update it again (IMP88?).
Sam