rick@oresoft.UUCP (Rick Lahrson) (01/01/70)
In article <2122@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes: >In article <70@oresoft.UUCP> rick@oresoft.UUCP (Rick Lahrson) writes: >>I say the compiler should model the target hardware, and generate >>code for that. > >Wait a second! We have two models, the language model and the machine model. >The compiler itself does not model anything, it translates between two models. >I submit the language should not model any SPECIFIC machine. (Note that most >algorithmic languages assume a rather generic von Neuman architecture.) > >The compiler should implement the language's model on the machine's model as >best as possible given the development resources. As long as the language >model is faithfully implemented, how close the resulting code is to the machine >model is a performance issue. (All bets are off if you are mixing languages.) OK, I'm starting to catch on. I'm a relative neophyte at posting to the net, with its wide ranging readership (I'm used to discussing such topics with just my fellow compiler writers, and there's a large body of things understood as background, so my communications have come to rely on that -- I'll be more rigorous in the future). Yes, compilers deal with two models: the language and the target machine (or pseudo-machine -- in this case the 68K, a real machine). When I said the compiler should model the target hardware, I meant that it should use its "mental model" of the target to determine how to generate code. I didn't suggest that a LANGUAGE should have anything to do with specific hardware, just the compiler (specifically, just the "back end" (code generator) of the compiler). And yes, it is exactly a performance issue. That's what offends me about BPTR's -- they waste time and space. I don't know BCPL, and maybe that voids my right to an opinion about BPTR's, but certain compilers I DO know about can actually translate "add one word" into "add four bytes"! 8-) Seems to me BCPL should have been able to do that, too. Sure, I'm willing to let this topic die. 8-) -- Rick Lahrson ...tektronix!oresoft!rick Disclaimer: If I ever speak for anyone but me, I'll warn you in advance.
rick@oresoft.UUCP (Rick Lahrson) (01/01/70)
In article <5073@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >... No hard feelings, I hope? Absolutely not. Only respect and appreciation. ><>[Referring to BCPL and it's pointers in AmigaDOS.] >As someone else pointed out, you have two different models: the >hardware model, and the model the language has. The compiler can't do >anything about them; it just has to live with them. For many languages >(Pascal, COBOL, FORTRAN, Icon, Snobol, LISP, etc.) the language model >just has "abstract" objects in it (integers, floats, strings, etc) and >they can be mapped to something reasonable on just about any machine. Aye, there's the rub. I don't find BPTR's very reasonable. >On the other side, BCPL *insists* that the machine has words, and >words have three properties: 1) They are at least 16 bits long. 2) >they are long enough to hold a pointer to a word, and 3) adding 1 to >an address gives the address of the next word. On a word address >machine, this works just fine. But on a byte-addressed machine, you >have to jump through to make things work. Hmmm. Maybe I need to learn a little bit about a language before I bitch about its implementation. ... Nawwww. 8-) Apparently then, BCPL doesn't distinguish between numeric objects and pointers? I don't know BCPL, but if it distinguishes pointers from other things, it could have scaled its pointer arithmetic (as C does) in order to better fit the target machine. Oh, well. It's a dead horse. We definitely have BPTR's in our lives for some time to come. 8-( ><I think this is the first time I've been publicly "Oh, horse puckied". ><Kinda makes me scared to offer further postings. 1/2 8-) >Don't do that! Normally, your postings make lots of sense. I wanted to >make sure nobody mistook the misinterpretation for truth! 1/2 :-). That's just what I needed to hear. Thanks. Purrrr. -- Rick Lahrson ...tektronix!oresoft!rick Disclaimer: If I ever speak for anyone but me, I'll warn you in advance.
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/10/87)
[This is being moved from comp.sys.amiga to comp.lang.misc - mwm]
In article <66@oresoft.UUCP> rick@oresoft.UUCP (Rick Lahrson) writes:
<Please! It's not any compiler's responsibility, nor is it appropriate
<for a compiler, to do things the programmer didn't ask for. A compiler's
<job is translating one language into another, maintaining semantic
<equivalence.
Oh, horse pucky. A compiler should do a *lot* more than that. To save
space, I'm going to say "do X" when I actually mean "generate code to
do X."
For instance, almost every compiler has some prelude that needs to be
run before the compiled code starts running. That needs to be taken
care of. Other things include type checking, both at compile time and
at run time if apropriate. Array bounds checking, ditto. Stack and
heap management. Possibly garbage collection. I'm sure there's more,
if I could think of it.
The job of translating from one language to another and maintaining
semantic equivalence is a the job for a translator. A compiler is a
special case of that. But so is an assembler, or yacc, or lex, or a
host of similar tools. A compiler that does nothing else is little
more than a high-level assembler.
[Referring to BCPL and it's pointers in AmigaDOS.]
<stupid, disgusting BPTR's. (Now there's a job that a compiler SHOULD
<be able to do -- generate code that relates to the target machine!)
But you've got to convince the target machine to look like the machine
model the compiler wants to generate code for. The best you can hope
for when the compilers model and the manufacturers model clash badly
(like one being word addressed and the other byte addressed) is that
the language will be consistent with itself. BCPL manages to do that
on the Amiga, but you lose if you want to interface it to something
else. C on the CRAY does that, but those (*&(*&^ byte pointers give
headaches to people dealing with assembler.
<mike
--
Must have walked those streets for hours, Mike Meyer
In the dark and in the cold, mwm@berkeley.edu
Before I really could accept, ucbvax!mwm
There's no place called hope road. mwm@ucbjade.BITNETrick@oresoft.UUCP (Rick Lahrson) (09/10/87)
In article <5042@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >In article <66@oresoft.UUCP> rick@oresoft.UUCP (Rick Lahrson) writes: ><Please! It's not any compiler's responsibility, nor is it appropriate ><for a compiler, to do things the programmer didn't ask for. A compiler's ><job is translating one language into another, maintaining semantic ><equivalence. > >Oh, horse pucky. A compiler should do a *lot* more than that. [Long description of obvious things a compiler and run-time library do] I at least should have said "functional" instead of "semantic", I guess. Boy, am I embarrassed. The remark that so irritated Mike, pulled out of context above, makes it look like I said a compiler should act like an assembler. That's not what I meant. What I was trying to say (obviously, I missed the mark) was that a compiler shouldn't be used to do a job properly done by the operating system. I thought that would be clear from the original context. I guess it wasn't. >[Referring to BCPL and it's pointers in AmigaDOS.] ><stupid, disgusting BPTR's. (Now there's a job that a compiler SHOULD ><be able to do -- generate code that relates to the target machine!) > >But you've got to convince the target machine to look like the machine >model the compiler wants to generate code for. Hmph. I say the compiler should model the target hardware, and generate code for that. > <mike I think this is the first time I've been publicly "Oh, horse puckied". Kinda makes me scared to offer further postings. 1/2 8-) -- Rick Lahrson ...tektronix!oresoft!rick Disclaimer: If I ever speak for anyone but me, I'll warn you in advance.
crowl@cs.rochester.edu (Lawrence Crowl) (09/11/87)
In article <70@oresoft.UUCP> rick@oresoft.UUCP (Rick Lahrson) writes: >In article <5042@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes: >>In article <66@oresoft.UUCP> rick@oresoft.UUCP (Rick Lahrson) writes: >>>Now there's a job that a compiler SHOULD be able to do -- generate code that >>>relates to the target machine!) >> >>But you've got to convince the target machine to look like the machine >>model the compiler wants to generate code for. > >Hmph. I say the compiler should model the target hardware, and generate >code for that. Wait a second! We have two models, the language model and the machine model. The compiler itself does not model anything, it translates between two models. I submit the language should not model any SPECIFIC machine. (Note that most algorithmic languages assume a rather generic von Neuman architecture.) The compiler should implement the language's model on the machine's model as best as possible given the development resources. As long as the language model is faithfully implemented, how close the resulting code is to the machine model is a performance issue. (All bets are off if you are mixing languages.) -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.arpa Computer Science Department ...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/12/87)
In article <70@oresoft.UUCP> rick@oresoft.UUCP (Rick Lahrson) writes:
<I at least should have said "functional" instead of "semantic", I guess.
<Boy, am I embarrassed. The remark that so irritated Mike, pulled out of
<context above, makes it look like I said a compiler should act like an
<assembler.
That's what I took it to mean. Since I *like* very-high-level
languages, I got upset about the suggestion that my favorite languages
features didn't belong in a compiler! Functional I still have problems
with, but that's not so upsetting. No hard feelings, I hope?
<>[Referring to BCPL and it's pointers in AmigaDOS.]
<><stupid, disgusting BPTR's. (Now there's a job that a compiler SHOULD
<><be able to do -- generate code that relates to the target machine!)
<>
<>But you've got to convince the target machine to look like the machine
<>model the compiler wants to generate code for.
<
<Hmph. I say the compiler should model the target hardware, and generate
<code for that.
As someone else pointed out, you have two different models: the
hardware model, and the model the language has. The compiler can't do
anything about them; it just has to live with them. For many languages
(Pascal, COBOL, FORTRAN, Icon, Snobol, LISP, etc.) the language model
just has "abstract" objects in it (integers, floats, strings, etc) and
they can be mapped to something reasonable on just about any machine.
On the other hand, languages that try to live close to the machine
(like C and BCPL) have less abstract types (integers, bytes) that have
certain properties. For instance, C insists that there's something
called a char, it holds exactly one char, and it's addressable. On
byte-addressable machines, this works great. But on word addressable
machines, you have to jump through hoops to fake byte pointers (or do
other ugly things).
On the other side, BCPL *insists* that the machine has words, and
words have three properties: 1) They are at least 16 bits long. 2)
they are long enough to hold a pointer to a word, and 3) adding 1 to
an address gives the address of the next word. On a word address
machine, this works just fine. But on a byte-addressed machine, you
have to jump through to make things work.
Mixing the two is a *bad* thing. On AmigaDOS, you get BPTRs. On
Unicos, I get ugly C byte pointers. The compilers in question can't be
blamed for either. Neither can the language designers. The people to
blame are the people who decided to mix the two.
<I think this is the first time I've been publicly "Oh, horse puckied".
<Kinda makes me scared to offer further postings. 1/2 8-)
Don't do that! Normally, your postings make lots of sense. I wanted to
make sure nobody mistook the misinterpretation for truth! 1/2 :-).
<mike
--
And then up spoke his own dear wife, Mike Meyer
Never heard to speak so free. mwm@berkeley.edu
"I'd rather a kiss from dead Matty's lips, ucbvax!mwm
Than you or your finery." mwm@ucbjade.BITNETmwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (09/15/87)
In article <72@oresoft.UUCP> rick@oresoft.UUCP (Rick Lahrson) writes: <In article <5073@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: <Hmmm. Maybe I need to learn a little bit about a language before I <bitch about its implementation. ... Nawwww. 8-) <Apparently then, BCPL doesn't distinguish between numeric objects and <pointers? Right. BCPL is a language with *balls*. None of this silliness with types :-). For instance, you can do: let func(arg) be // declaring a function $( let x, y, z = 1, ? -1 // local variables ... // initialization code func = func + xx // arrange to skip over initialization // next time; xx is size of the code ... // in questoin. $) All variables are a *word*, and they hold a bit pattern. The compiler doesn't make any distinction above that - pointer to code, pointer to data, ints, it don't matter. And yes, to add a float to a float, you have to use #+ instead of +. Note that someone wrote a program which "implied" the type of variables, then did type checking on that basis throughout the rest of the program. All in BCPL, of course. This is starting to get esoteric. I'll point out that I've only seen a few languages that do types "right" (BCPL is one, C isn't), and request that further discussion move to email. <mike -- Come all you rolling minstrels, Mike Meyer And together we will try, mwm@berkeley.edu To rouse the spirit of the air, ucbvax!mwm And move the rolling sky. mwm@ucbjade.BITNET
peter@sugar.UUCP (Peter da Silva) (09/19/87)
BCPL: The Language and its Compiler. Martin Richards and Colin Whitby-Strevens. Cambridge University Press, 1980, 1982. Library of Congress #77-91098 ISBN 0 521 21965 5 hard covers ISBN 0 521 28681 6 paperback -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Insert cute saying here.