🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Uday Kurkure Fri, 03 Oct 1986 19:11
Re: One Pass compiler
#545
Author: Uday Kurkure
Date: Fri, 03 Oct 1986 19:11
44 lines
1634 bytes

>	Actually, you can note the fact that whatever type the symbol has
>    must be compatable with how it is being used, and check that against
>    the actual declaration when you see it.  For example, if I see a
>    function call:

>  intvar := funct( 5.0, "test", 7 );

>   I can note that funct must return a type that can be assigned to an int,
>   and accept a floating point, char array, and integer argument;  then,
>   when I see a declaration of funct, I can check against this usage, and
>   determine whether the previous usage was correct.


     What happens if the intvar is also declared forward ?

     Such things can lead to lot of bookkeeping. Consider a
     following statment and lot of occurrences of the similar
     statements.

     .
     .
     a1 := a1 * f1( x,y,z )+ a2 + a3 + f3............* x100
     .

     ..

     VAR
       x100: type;
       .
       .
       .
       .
       a1: type100


    etc etc.
    

   This could be reasonably difficult to do with one pass.

                                 ..Uday
-------
Re: One Pass compiler
#551
Author: bobc
Date: Mon, 06 Oct 1986 16:49
74 lines
3343 bytes
>>	Actually, you can note the fact that whatever type the symbol has
>>    must be compatable with how it is being used, and check that against
>>    the actual declaration when you see it.  For example, if I see a
>>    function call:
>
>>  intvar := funct( 5.0, "test", 7 );
>
>>   I can note that funct must return a type that can be assigned to an int,
>>   and accept a floating point, char array, and integer argument;  then,
>>   when I see a declaration of funct, I can check against this usage, and
>>   determine whether the previous usage was correct.
>
>     What happens if the intvar is also declared forward ?
>

I feel that a one pass compiler can't easily handle forward
declarations as stated in the language definition.  I also have used
the "ETHZ" one pass compiler, and feel that the limitations that Wirth
added are reasonable.  The first limitation (and not a unreasonable
one) is that variables must be declared before they are used.  Also
TYPE must be defined before they are used (with the exception of the
normal POINTER TO undefinedtype defines).  Third is that forward
declaritions of PROCEDUREs is required using the FORWARD directive.

At one point I felt that "backpatching" could solve the problem as in:

    intvar := funct( 5.0, "test", 7 );

But since I have done some work with the one pass compiler (and have
seen the source) it turns out that there are some problems.  The
first is you can't tell what type any of the arguments are.  For
example what if the parameters were all "ARRAY OF WORD" (BYTE is
another form of the same thing on the One Pass Compiler).  For example
based on what the ETHZ One Pass Compiler does:

PROCEDURE funct(v1,v2,v3:ARRAY OF BYTE):INTEGER; FORWARD;

....
    intvar := funct(5.0, "test", 7);

Expands to the following code:

    PUSH.W	#3
    PUSH.L	ADR(Const5.0)
    PUSH.W	#3
    PUSH.L	ADR(Const"test")
    PUSH.W	#1
    PUSH.L	ADR(Const7)
    CALL	funct
    POP.W	intvar

Note that arrays are passed by address, and the called function then
copies them.  This code is much different then the expected:

    PUSH.L	#5.0
    PUSH.W	#3
    PUSH.L	ADR(Const"test")
    PUSH.W	7
    CALL	funct
    POP.W	intvar

This means that you would have to do so much backpatching as to be come
almost unreasonable, (not completely impossable but almost)  It would
seem almost as reasonable to make a two pass compiler.  I do however
feel that using variables before they are defined is unreasonable, and
I also find the "FORWARD" directive a small price to pay for a very
fast compiler.

Bob Campbell
Teltone Corporation		18520 - 66th AVE NE
P.O. Box 657			Seattle, WA 98155
Kirkland, WA 98033

{amc,dataio,fluke,hplsla,sunup,uw-beaver}!tikal!bobc
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads