Smalltalk-80 compiler ? 
Author Message
 Smalltalk-80 compiler ?

I am considering writing a Smalltalk-80 compiler as a project course. I don't
know Smalltalk very well, and am looking for advice from Smalltalk experts
on the following comments:

The general idea would be to provide a way for a programmer to create an
efficient executable containing only the code necessary for a particular
application to run, with all the low-level stuff inlined, and the remaining
message-passing stuff grouped into function calls, where multiple functions
will be created to deal with operator overloading, as if the language had
been statically typed. This will give the programmer the benefit of a Smalltalk
development environment with the advantage of allowing for a more efficient
executable to be created in the final stage. I would probably begin with
GNU's smalltak interpreter, and would definitely borrow the back-end from
some freely available compiler.

1. Does such a beast already exist ?

2. Could this be a useful tool ?

3. Is there something I am overlooking which might cause this project to
        balloon into a huge amount of work ?

        Thank you for any informed advice,
                                                Andrew.



Sat, 03 Feb 1996 12:16:47 GMT  
 Smalltalk-80 compiler ?
|> I am considering writing a Smalltalk-80 compiler as a project course. I don't
|> know Smalltalk very well, and am looking for advice from Smalltalk experts
|> on the following comments:
|>
|> The general idea would be to provide a way for a programmer to create an
|> efficient executable containing only the code necessary for a particular
|> application to run, with all the low-level stuff inlined, and the remaining
|> message-passing stuff grouped into function calls, where multiple functions
|> will be created to deal with operator overloading, as if the language had
|> been statically typed. This will give the programmer the benefit of a Smalltalk
|> development environment with the advantage of allowing for a more efficient
|> executable to be created in the final stage. I would probably begin with
|> GNU's smalltak interpreter, and would definitely borrow the back-end from
|> some freely available compiler.
|>
|> 1. Does such a beast already exist ?
|>
|> 2. Could this be a useful tool ?
|>
|> 3. Is there something I am overlooking which might cause this project to
|>   balloon into a huge amount of work ?
|>
|>   Thank you for any informed advice,
|>                                           Andrew.

Smalltalk is not a statically typed language, and I really don't believe it
can be made into one without an exponential code size increase.

As a basic sample, look at implementorsOf: #do:. (this would be a major place
where in-lining would help, because you can also save passing a block).
There's 30+ of them, all different. Most of them call other methods in the
class, so you probably need a different implementation for every subclass
of Collection, of which there are 90 in my image. If that means you need a 90-way
switch statement every time you encounter one, you'll be in big trouble
code-size-wise.

My estimate of the number of fully specialized methods you might need:
|meth|
meth := 0.
self do: [:cl |
        Transcript show: cl printString,' ';endEntry.
        cl withAllSuperclasses do: [:x |
                meth := meth + x methodDictionary size.
        ].
].
meth

meth = 1.3 million, in my image. I would guess that about half these methods
are _actually_ different, but there's no way you can compile even 1/10 of
these: the minimum machine code size for a method is at least 100 bytes: a lot
more if you're trying to inline 90-way switch statements.

You will also always need a real method dictionary for each class, because
you can't build a Smalltalk without perform:. Many classes in the base system
use it.

The ParcPlace compiler does a reasonable implementation of inlining a number
of things when compiling. But, about all it can do (and there's been a lot
of effort behind it) is conditionals (ifTrue:ifFalse:...), loops (whileTrue:,...)
and SmallInteger arithmetic. You should read some of there recent papers.
Also, look into the language Self, which tries to do some of what you're talking
about.

Also, there's no getting around the need for BlockClosures, and a stack-frame
implementation that supports this. C-language stacks won't work.

Also, you need garbage collection. Unless you are going to build a generational
scavenger, your system won't be fast.

Also, don't forget the library of system calls, although perhaps you can grab
these from GNU.

In summary, there's a whole lot of iceberg under that tip, and I wouldn't suggest
it as anything less than a multi-year research effort.

--
-------------------



Sat, 03 Feb 1996 22:12:16 GMT  
 Smalltalk-80 compiler ?

[....]

Quote:
>3. Is there something I am overlooking which might cause this project to
>       balloon into a huge amount of work ?

Regardless of the specifics of the case, the _globally_ and
_statistically_valid_ answer to this question has to be yes.  In
the particular instance, however, the experience gained might easily
be worth the candle.


Sun, 04 Feb 1996 00:30:28 GMT  
 Smalltalk-80 compiler ?
From digi!texsun!cronkite.Central.Sun.COM!west.West.Sun.COM!koriel!cs.utexas.edu!math.ohio-state.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!destroyer!nntp.cs.ubc.ca!cs.ubc.ca!harpoon.cs.ubc.ca!not-for-mail Wed Aug 18 12:32:19 CDT 1993
Article: 1959 of comp.lang.smalltalk
Path: digi!texsun!cronkite.Central.Sun.COM!west.West.Sun.COM!koriel!cs.utexas.edu!math.ohio-state.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!destroyer!nntp.cs.ubc.ca!cs.ubc.ca!harpoon.cs.ubc.ca!not-for-mail

Newsgroups: comp.lang.smalltalk
Subject: Smalltalk-80 compiler ?

Date: 17 Aug 93 04:16:47 GMT
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Lines: 24
NNTP-Posting-Host: harpoon.cs.ubc.ca

I am considering writing a Smalltalk-80 compiler as a project course. I don't
know Smalltalk very well, and am looking for advice from Smalltalk experts
on the following comments:

The general idea would be to provide a way for a programmer to create an
efficient executable containing only the code necessary for a particular
application to run, with all the low-level stuff inlined, and the remaining
message-passing stuff grouped into function calls, where multiple functions
will be created to deal with operator overloading, as if the language had
been statically typed. This will give the programmer the benefit of a Smalltalk
development environment with the advantage of allowing for a more efficient
executable to be created in the final stage. I would probably begin with
GNU's smalltak interpreter, and would definitely borrow the back-end from
some freely available compiler.

1. Does such a beast already exist ?

2. Could this be a useful tool ?

3. Is there something I am overlooking which might cause this project to
        balloon into a huge amount of work ?

        Thank you for any informed advice,
                                                Andrew.

From digi!texsun!cronkite.Central.Sun.COM!sixgun.East.Sun.COM!seven-up.East.Sun.COM!west.West.Sun.COM!koriel!cs.utexas.edu!math.ohio-state.edu!howland.reston.ans.net!torn!nott!bnrgate!bcars267!bcarh51f!trevor Wed Aug 18 12:38:03 CDT 1993
Article: 1966 of comp.lang.smalltalk
Path: digi!texsun!cronkite.Central.Sun.COM!sixgun.East.Sun.COM!seven-up.East.Sun.COM!west.West.Sun.COM!koriel!cs.utexas.edu!math.ohio-state.edu!howland.reston.ans.net!torn!nott!bnrgate!bcars267!bcarh51f!trevor

Newsgroups: comp.lang.smalltalk
Subject: Re: Smalltalk-80 compiler ?

Date: 17 Aug 93 14:12:16 GMT


Organization: bnr
Lines: 79
Nntp-Posting-Host: 47.141.3.163

|> I am considering writing a Smalltalk-80 compiler as a project course. I don't
|> know Smalltalk very well, and am looking for advice from Smalltalk experts
|> on the following comments:
|>
|> The general idea would be to provide a way for a programmer to create an
|> efficient executable containing only the code necessary for a particular
|> application to run, with all the low-level stuff inlined, and the remaining
|> message-passing stuff grouped into function calls, where multiple functions
|> will be created to deal with operator overloading, as if the language had
|> been statically typed. This will give the programmer the benefit of a Smalltalk
|> development environment with the advantage of allowing for a more efficient
|> executable to be created in the final stage. I would probably begin with
|> GNU's smalltak interpreter, and would definitely borrow the back-end from
|> some freely available compiler.
|>
|> 1. Does such a beast already exist ?
|>
|> 2. Could this be a useful tool ?
|>
|> 3. Is there something I am overlooking which might cause this project to
|>   balloon into a huge amount of work ?
|>
|>   Thank you for any informed advice,
|>                                           Andrew.

Smalltalk is not a statically typed language, and I really don't believe it
can be made into one without an exponential code size increase.

As a basic sample, look at implementorsOf: #do:. (this would be a major place
where in-lining would help, because you can also save passing a block).
There's 30+ of them, all different. Most of them call other methods in the
class, so you probably need a different implementation for every subclass
of Collection, of which there are 90 in my image. If that means you need a 90-way
switch statement every time you encounter one, you'll be in big trouble
code-size-wise.

My estimate of the number of fully specialized methods you might need:
|meth|
meth := 0.
self do: [:cl |
        Transcript show: cl printString,' ';endEntry.
        cl withAllSuperclasses do: [:x |
                meth := meth + x methodDictionary size.
        ].
].
meth

meth = 1.3 million, in my image. I would guess that about half these methods
are _actually_ different, but there's no way you can compile even 1/10 of
these: the minimum machine code size for a method is at least 100 bytes: a lot
more if you're trying to inline 90-way switch statements.

You will also always need a real method dictionary for each class, because
you can't build a Smalltalk without perform:. Many classes in the base system
use it.

The ParcPlace compiler does a reasonable implementation of inlining a number
of things when compiling. But, about all it can do (and there's been a lot
of effort behind it) is conditionals (ifTrue:ifFalse:...), loops (whileTrue:,...)
and SmallInteger arithmetic. You should read some of there recent papers.
Also, look into the language Self, which tries to do some of what you're talking
about.

Also, there's no getting around the need for BlockClosures, and a stack-frame
implementation that supports this. C-language stacks won't work.

Also, you need garbage collection. Unless you are going to build a generational
scavenger, your system won't be fast.

Also, don't forget the library of system calls, although perhaps you can grab
these from GNU.

In summary, there's a whole lot of iceberg under that tip, and I wouldn't suggest
it as anything less than a multi-year research effort.

--
-------------------



Mon, 05 Feb 1996 02:45:41 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Smalltalk/80 Compiler

2. Smalltalk-80 compiler for IBM-PC compatables

3. Smalltalk 80 & Smalltalk V Professionals Wanted

4. SMALLTALK 80 ***** Software Engineer - Essex **** SMALLTALK

5. REQUEST: Differences between Gnu Smalltalk & Smalltalk-80

6. Smalltalk/V286 vs Smalltalk-80?

7. Smalltalk V/286 to Smalltalk 80

8. Translating Smalltalk V/286 to Smalltalk-80

9. Who have the Z-80 Assembly Compiler Program ??

10. Ada Compilers for Sun3/80

11. need MS fortran 80 compiler

12. FORTRAN Compiler for AT&T 3b2-1000 Model 80 with MAU

 

 
Powered by phpBB® Forum Software