From: neeri@iis.ethz.ch (Matthias Neeracher)
Subject: Re: The need for an assembler (was: Favorite CPU)
Organization: Integrated Systems Laboratory, ETH, Zurich
	<1992Aug27.075325.16635@news.columbia.edu>
	<NEERI.92Aug27180026@iis.ethz.ch>
	<1992Aug29.215659.15190@news.columbia.edu>
Date: Tue, 1 Sep 1992 12:52:21 GMT

In article <1992Aug29.215659.15190@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>In article <NEERI.92Aug27180026@iis.ethz.ch> neeri@iis.ethz.ch (Matthias Neeracher) writes:
>>In article <1992Aug27.075325.16635@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
>>>In article <NEERI.92Aug26154345@iis.ethz.ch> neeri@iis.ethz.ch (Matthias Neeracher) writes:
>>>>
>>>>>The test for the condition is 
>>>>>whether it's possible to transfer out of a loop, and then go back in with
>>>>>out losing any context,
>>>>
>>>>This is clearly illegal in Pascal.
>>>
>>>You left out the other half of the test, which was to stay within a larger
>>>loop structure surrounding the exited loop without loss.
>>
>>And this is clearly *legal*.
>
>Yes, but no.  You can't rejoin where you were by jumping back to the same
>level of the loop you formerly were in.

Ah, I think I misunderstood the "stay" in your sentence.

>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)


>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.

>>>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.

>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).

>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.

>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?

>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++.

>>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.

>BTW, I never said jumping *into* loops, I said rejoining them.

I'll grant you this linguistic distinction, but remain unimpressed of the
concept.

>>>[...] 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.

>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 :-)

>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 ?

>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).

>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.

>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 :-)

>>>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.


>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.

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?

>>>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.

>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.

>>>[...]  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?

>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.

Matthias

-----
Matthias Neeracher                                      neeri@iis.ethz.ch
  "And that's why I am going to turn this world upside down, and make
   of it a fire so *bright* that someone real will notice"
                                -- Vernor Vinge, _Tatja Grimm's World_

Newsgroups: alt.folklore.computers