From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Thu, 3 Sep 1992 05:45:03 GMT

In article <NEERI.92Sep1135221@iis.ethz.ch> neeri@iis.ethz.ch (Matthias Neeracher) writes:
>
>>Also, I guess you don't realize that
>>when you do this form of "panic" exit, the language spec is sloppy enough
>>that the stack can "grow" because of junk left behind.  There are some
>>implementations that do this.
>
>Now, is it "the language spec" or "some implementations"? If it is the former,
>could you indicate which document you consider the language spec and where it
>says someting like this? (Something like "Section 5.6.13 of the ISO Pascal
>standard: Implementations shall be free to leave junk on the stack in the case
>of a goto" will do just fine)

I'll leave it to you to post where in the spec it says you can't do that; it
is sufficient on my part to point out that some do, and the language spec
doesn't give a hoot either way.  Try to reason your own notion of the generated
binary code to implement it, and then notice whether or not it matters whether
the stack is "dirty" or not for your running programs.  My point is that the
fact that the stack could be dirty in that sense is part of the reason why
the kind of restrictions I would like to see go away cannot do so, without
cleaning up the "act" of the rest of the language.  It was defined sloppily
enough that this is true, while older languages such as PL/I are cleaner
on this point by design.  Part of this is the consequence of a single-pass
compilation, because without forward knowledge, it's hard to build the
right code to implement some of this.

>
>
>>In any case, this is an arbitrary lame restriction of the language.  PL/I
>>came first; it and Fortran allow unchanged loop re-entry.  It is too much of
>>a cheap compiler solution to disallow this form than any other design reason
>>to disallow it.  A "smarter" compiler knows how to make this usage innocuous.
>
>And a smarter programmer knows how to make the usage superfluous.

Superfluous is an opinion of a programmer who chooses to ignore available
techniques.  Double-precision sine is superfluous to those who never need it,
but not to someone who needs it.  You seem to defend programmers molded in
the image of the limitations of language implementations.  But these languages
aren't as flexible in certain ways as former ones.  I would hope that newer
languages are supersets of old ones in terms of possible techniques to employ,
but this doesn't seem the case.  Yet, you won't acknowledge that this is a
"political" process in the sense of will imposition, etc.  In many ways some
people look at C as a "revolt" against this trend, and to that extent I would
agree that it's a step in the right direction.  My arguments against C are on
an entirely different "plain" from these primarily PASCAL issues.

>
>>>>The point of the matter is that by making it illegal, you limit the ability to
>>>>create straight-forward structures without resorting to "equivalent" forms
>>>>that sometimes aren't so equivalent.
>>>
>>>Jumping out of a loop and back in again is straight-forward ? Show me an
>>>algorithm where the straight-forward solution consists of jumping out and into
>>>a loop.
>>
>>Very simple, to conditionally call some code that isn't really a subroutine,
>>but can exist outside of the loop.
>
>If it can exist outside of the loop, it should also be able to exist inside it.

A few months back someone pointed out that this isn't true for their rather
lengthy program.  You would require of them the overhead of excessive 
modularity, and they would tell you where to go :-).

>
>>Subroutine calls in many languages are
>>often an "expensive" overhead in the running program.  Ask some of the people
>>who have posted here who run "real* applications (crunch-wise).  Some people
>>nitpick about "peep-hole" techniques, etc., when this could be a glaring 
>>fault.  Abiding by this restriction begs the larger category of having to
>>not call subroutines but instead (macro-style) regenerate the code multiple
>>times in-line.
>
>Now, wait a minute. If you do a goto to a section that is used "multiple
>times", you are in fact doing an expensive subroutine call (since you
>presumably will have to do a goto back to different places).
>

No, the code can have conditions on it that require it to loop back where
needed.  This isn't expensive at all, in fact it can be rather efficient
compared to a more "stuctured" approach.  I would point out that this can
look suspiciously like spaghetti code, and would insist it be heavily
documented because it's not immediately obvious.  I don't mind code that isn't
mindless, as long as it's documented what's going on.

>>This is a quite old technique, and can be applied rather elegantly.
>
>If so, you have not demonstrated how.
>
>>Designing
>>a language to cramp legitimate style is not my idea of a good language design.
>
>And designing a language to lend legitimity to a cramped style is not *my* idea
>of a good language design.
>
>>You can never have too many ways to express a problem solution.
>
>I disagree.

Obviously you do.  This is a philosophical question, not a programming one,
since you want people to have limited choices, and I don't want limitations.
However, you "run" to C to avoid practicing what you preach.  I seek
assembler to avoid the restrictions altogether.

>
>>I suggest that
>>Pascal has a "skew" in it to serve the interests of groups that would 
>>essentially limit "programming freedom" to their "brand" of programming
>>methods and techniques *only*.
>
>Men in trenchcoats kicking in your door and putting Pascal compilers on your
>harddisk?

Figuratively yes, since PASCAL is perceived as something larger than life, 
and has to be reckoned with as someone's notion of a programming solution
to a problem more often than I'm comfortable with.  If an inflexible language
gains popularity, programming freedom becomes limited.  In all probability
C will suffer this fate when the next more obfuscated and inefficient trendy
set of wimpy languages comes out.

>
>>This is one of the arguments on why to program in
>>assembler: you make up your own rules to fit your own skills, preferences, 
>>and the parameters of the problem.
>
>Actually, it's *because* I can make my own rules to fit the parameters of the
>problem that I do 96% of my work in C or C++.

You are just proving my arguments against yours re PASCAL.

>
>>>The only 
>>>HLLs I know that allow jumping back into loops are Fortran and some BASIC
>>>dialects (I don't know PL/I, nor do I have a real desire to know). The BASIC
>>>solution leaves the stack in a mess, while Fortran merely leaves the
>>>Programmer's mind in a mess. In neither language have I seen a convincing
>>>reason to allow jumping into loops. 
>>
>>Efficiency of running code isn't a factor here either way,
>
>I agree.
>
>>I strongly suggest you look at PL/I rather closely.  Various "scientific"
>>subsets have been written over the years to avoid all of the IBM "overhead"
>>of decimal arithmetic and other "extraneous" data types retaining otherwise
>>total feature compatibility, etc.
>
>Any language that spawns subsets that are not considered to be severely limited
>was probably too big to begin with.

Technically this is true, but the subsets were invented because the ideas
in PL/I are sound.  The problem is that since IBM implemented it, they imposed
a lot of crap only found at the time on 360-class machines such as decimal
hardware, primarily to make it hard to implement on competitor's machines.
There is quite demented stuff in full-blown IBM PL/I, such as a simple
assignment statement like
I=3;

The problem is that 3 is a decimal constant which occupies some BCD-DIGIT
storage, and a subroutine call to a decimal => binary conversion routine
will be made to create a temporary binary 3 to store into the integer's
storage space.  The scientific PL/I subsets threw away decimal entirely
and force constants to be as in Fortran, just floating and integer.  In
IBM PL/I it may be faster to use
DECLARE THREE FIXED BINARY INITIAL (3);

I=THREE;

Even IBM PL/I does the assigment statement efficiently in this second case.

For this kind of reason, the subsets arose.

>
>>BTW, I never said jumping *into* loops, I said rejoining them.
>
>I'll grant you this linguistic distinction, but remain unimpressed of the
>concept.

That's ok, just don't disallow others from using it.  There are too many
languages that are enforcing that restriction.

>
>>>>[...] I prefer to take this argument to be PASCAL versus PL/I.  In PL/I
>>>>the functions are recursive or not as I choose,
>>>
>>>Why should a programmer have to specify that a function is recursive? That's
>>>what compilers are for.
>>
>>Wrong, cheap compilers and simplified language specs are for allowing the
>>compiler to be a shoddy implentation of a shoody language.
>
>I'm afraid I don't get your point.

If a language lacks specs to enforce the recursiveness or lack thereof when
the programmer is perfectly aware of the advantages of doing it either way
when required, invariably the language gets implemented with overhead.

>
>>The compiler
>>can't possibly know what you have in mind, so you have to tell it what you
>>intend.
>
>Yes, that's what source code is for :-)

Thus my answer above.

>
>>Clearly, most reasonable architectures have subroutine call methods
>>that can take advantage of non-stack less-cycle methods.
>
>And most reasonable animals are reptiles weighing a few tons ? Do I have to
>conclude that you don't consider any of the 8XXX, 8XXXX, 6XXX and 68XXX
>processors reasonable ?

On this point, that's true.  I never claimed that Motorola or Intel knew
anything remarkable about architecture design.  I doubt if I am alone in
having disdain for them.  Stack-oriented subroutine calls as an absolute
requirement is just plain silly.  The only excuse I'll give to either company
is that they were likely influenced by these wimpy languages where you can't
take advantage of the feature if it were present, so they foolishly assumed
it has no worth.  Hopefully more RISC machines will arise that do things the
way they used to be commonplace.

>
>>PASCAL for example totally cops out on this point, and
>>doesn't have syntax to instruct the compiler as to your intention,
>
>Because it is not needed. A compiler can detect that a procedure is not called
>recursively (With some restrictions when procedure variables are used).

In any realistic way, I doubt it, since apparently you are looking at
implementations where it doesn't matter much, since little improvement can
be made either way.

>
>>thus all
>>calls are the high-overhead kind; there's just no way to specify the more
>>efficient alternatives.  (If you are only familiar with machine architectures
>>where the subroutine call mechanism is *only* via stack then you are totally
>>missing this point.  Such machines are inherently inferior on this aspect of
>>their design compared to otherwise better machines with a choice.
>
>It seems that maost computers built in the last 10 years have lived quite
>happily with this lack of choice.

Lived, or crawled?  Just because the clock runs faster, doesn't mean that
there isn't a lot of extraneous wheel-spinning going on.

>
>>In any case, PL/I is a language where you can inform the compiler that the
>>subroutine is intended for either recursive (stack-save) or non-recursive
>>(no stack-save) calling convention, and reap the benefits.  You regain total
>>control over your architecture on this point while PASCAL ignores this issue
>>totally.
>
>As I don't own a cardpunch, I doubt that I will ever be able to reap the
>benefits of PL/I :-)

As it happens, I do, and also a card-reader.  But in any case PL/I is available
on other machines, just not on MACs and the like.

>
>>>>Globality of variables is
>>>>determined by my usage, not by arbitrary wimpy restrictions of the compiler,
>>>
>>>*Shudder*. How exactly does this work ?
>>
>>Very simple:
>>
>>I can use true top-down order, or PASCAL-like order, or anything else I
>>choose.  The scope of variables is determined by my placement of their
>>declarations.
>
>Aha, this was a terminology clash, as I don't consider declarations to be
>usage.
>
>> There's a fundamental conceptual
>>problem here: is the compiler written to suit the programmer, or is the
>>programmer here to suit the compiler?
>
>As I said before, the compiler is written to suit the programmer who *uses* it.

So, the "political" problem surfaces again, since the programmer was molded to
use it by training him to merely know how to use only what was provided to
him, not what could have been available where the hidden agenda discussed by
myself and others not present.

>
>
>>Why should I care about how many passes a compiler makes over my code?  This
>>is a ludicrous issue, since a compiler can tokenize my input down to a
>>much smaller size and then make fast passes over that in short order.  Also,
>>with larger and larger machines these days, who cares how much memory it 
>>takes to compile in?
>
>After having seen you ignore the same arguments innumerable times in the
>Assembly vs. C debate, I must say that I'm somewhat surprised.

I have never raised any such issue.  I couldn't care less how much resources
are used getting my extra-small assembly language binary created.  In fact, 
I would encourage speed over space lookup techiques wherever possible.
Don't confuse development resources with running resources.  Besides, you
don't compile or assemble anything larger than the largest module of the
application.

>
>Personally, I don't find compilation speed very important, but on the other
>hand, some compilers are *very* impressive, and I would take a C++ compiler
>with the spped of an Oberon compiler any day.
>
>>  Perhaps this is
>>a down side of the coin about "modern" compilers: they are cheap 
>>implementations that take shortcuts as compared to "older" compilers.
>
>I take it you have tried every single one of the four or five modern compilers
>to have come to this conclusion?

I take it that you have ever tried *any* of the older ones to come to your
conclusion?

>
>>>>An
>>>>additional minor peeve: when the arg list for the function that was
>>>>forwarded is now known, why must it be left out of the definition.  I
>>>>have seen comments that attempt to fantasize about the repetition of the
>>>>arg list, but why do you have to leave it out?
>>>
>>>The reason is probably simple and ugly: Because it would cost time for the
>>>compiler to check the arguments and it would be dangerous for maintenance to
>>>leave them unchecked.
>>
>>[Modula-2 stuff deleted]
>>
>>I would think that it's dangerous for maintenance that people are in fact
>>creating fantasy lists of args passed in the *comment* after the stubbed
>>header.
>
>Yes, but not quite as dangerous as the unchecked arguments outside of the
>comment.
>

Who is asking the args to be unchecked?  I want them to be redundant
totally for greater reliability.

>>Again, why should I care about an insignificent amount of scan
>>time of a compiler?  This isn't a pass we're discussing, since the
>>comment has to be parsed anyway, rather just the appropriate lookups for
>>the items in question already present from the FORWARD statement.
>
>Personally, I would prefer the aerguments to be repeated and checked, too. I
>was just pointing out the likely rationale behind leaving tehm out.

So, now you're a devil's advocate as well?

>
>>>>[...]  And unnecessary isn't a
>>>>replacement for undesirable.  Why have a language that limits my ability
>>>>to express ideas in alternate ways?
>>>
>>>A programming language that allows too many ways to express the same idea is
>>>likely to produce "sublanguages", i.e., Programmers use exclusively a subset of
>>>the language and different programmers use different subsets.
>>
>>I would *hope* that this would occur.  It helps point out where language
>>elements are excess baggage.
>
>But after it has been pointed out, why not leave the baggage out?

Simply because one man's baggage is another man's cabbage.  And that's why
they call it programming :-).

>
>>Admit it: there seems to be a "political" undertone to the implications of
>>this discussion.  I am for more, not less, programming freedom.
>
>So am I, but I think programming freedom is not gained by burdening languages
>with innumerable features, but by having programmers design their own
>programming languages to suit their design philosophy. 

But our world is too commercial for that to ever happen.  Languages are used
as targets of opportunity by money people.  All to quickly something can be
regimented before it's been explored well enough to know if it should be
finalized that much.

cjl

Newsgroups: alt.folklore.computers