From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: alt.folklore.computers,comp.lang.misc
Subject: Re: BCPL
Date: 26 Jan 1993 13:27:06 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
	<SPACKMAN.93Jan23165527@disco-sol.dfki.uni-sb.de>
	<1993Jan25.182113.6275@osf.org>
Reply-To: stephen@acm.org
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: dbrooks@osf.org's message of Mon, 25 Jan 1993 18:21:13 GMT

In article <1993Jan25.182113.6275@osf.org> dbrooks@osf.org (David Brooks) writes:
|spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman) writes:
|| Just exactly the same as C, given a tolerably intelligent compiler, but
|| without the "extra unnecessary" datatypes. Not that data types are ever
|| extra or unnecessary, but you see what I mean - you could generate
|| identical object code once you had re-extracted the type info from the
|| source.
|
|No; in C, a pointer always knows what type it is pointing to, so "add 1"
|is actually compiled as "add sizeof base type".  In BCPL, there is not
|necessarily any information around at compile time as to what the
|programmer had in mind for this variable; all variables are declared
|without type.  "Add 1" always has to do just that.

You are forgetting that there is a compiler. A compiler is under no
compulsion to do what you THINK it's going to do, so long as the effect
is the same. Two sensible BCPL compilation techniques (with similar
results) would be, (a) to recover the type information by analysis (as
is done in modern lisp and OO compilers) and compile the same code as C
would (inserting casts, of course, if there are any effective puns); or
(b) propagate all the addressing shifts upstream in the hope that they
"top out" against constants, effectively generating the same code again.

This could be expensive in compilation effort, but it seems to me it
should pay off on any machine that can't do offset+shifted register
addressing modes for very very cheap.

Conversely, it is *absolutely* correct for a standard C compiler to use
BCPL-style pointer manipulations, inserting the shifts where there are
dereferences, conversions and casts, and always implementing addition
shiftlessly.  Uniform pointer representations are a programmer-invisible
optimisation in C, too.  This must needs be the case, in order to
support non-byte addressable machines.

|| |>    IF 4 <= x <= 8  $( ... $)
|| |Usually converted into two tests and a /\ in the first stage of syntactic
|| |analysis, though :-)
|| 
|| Oh, no, probably not. I'd guess (not knowing the language) that if x has
|| side effects you can tell the difference. Can it?

|The language didn't define how many times x is evaluated.  The standard
|analyzer would turn this into a shortcircuit evaluation when it deemed
|that safe, but no guarantees.

The implication being that it IS different from a conjunction, since a
conjunction would REQUIRE double evaluaiton of x (in the event that the
lower bound is satisfied), while from your description this only PERMITS
it.
----------------------------------------------------------------------
stephen p spackman    +49 681 302 5288(o) 5282(sec)    stephen@acm.org
      dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
----------------------------------------------------------------------
Newsgroups: alt.folklore.ghost-stories