Send mail to the CREATE web master
Index
Date: 96 Dec 03 2:31:41 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: display updating (again)
I have been playing with display updating when caching is off and have come
up with a simple hack to accomplish full functionality in this case
(hopefully!). The changed methods have been incorporated into
desktopColor.st at <http://ftp.tuwien.ac.at/~go/Squeak>. I am interested in
reports about speed and bugs. If I get positive feedback I will do some
cleanup of the display framework to lift my modifications from "hack"
status.
Georg
----
Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum
phon:(++43-1) 58801 - 5848
mail:gollmann@edvz.tuwien.ac.at
http://ftp.tuwien.ac.at/~go/Gollmann.html
Date: 96 Dec 03 6:33:49 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: Format for Squeak Mailing List--mail/news/web?
Hello all,
I'd just like to discuss the format of this discussion for a minute. Each of
the three main media for distributed asyncronous communication --email,
netnoise, and the WorldWierdWeb--have advantages and disadvantages.
In the past couple of weeks, I've been looking into several software packages
(e.g., WWWboard and HyperNews) that merge some of the best features of news
groups and web pages. I've been hoping to find a package that can take a mail
archive file (such as ours) and turn it into a threaded outline such as in
Netscape News or other tools.
Just for my information, how many readers have no Web access, or vastly prefer
the e-mailing list to a news group? How many of you use the indexed Web page I
set up?
Does anyone know of a package that would take our mail archive and make a
threaded web page a la HyperNews/WWWboard (and allow readers to post to the
list via mail or news)?
stp
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Dec 03 7:26:00 am
From: james@clyde.as.utexas.edu (James McCartney)
To: stp@create.ucsb.edu, squeak@create.ucsb.edu
Subject: Re: Format for Squeak Mailing List--mail/news/web?
At 11:34 PM 12/2/96, Stephen Travis Pope wrote:
>Hello all,
>I'd just like to discuss the format of this discussion for a minute. Each of
>the three main media for distributed asyncronous communication --email,
>netnoise, and the WorldWierdWeb--have advantages and disadvantages.
I vastly prefer email. I have 16 Mb on my Mac, so cranking up Netscape 3
means I can run nothing else. Besides Netscape takes forever to launch.
For this reason I still use Netscape 2 a lot. Email is simple, fast and
doesn't crash as often as Netscape's bloatware.
MACINTOSH == Most
Applications
Crash,
If
Not
Then
Operating
System
Hangs
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Dec 03 5:03:45 pm
From: "David N. Smith" <dnsmith@watson.ibm.com>
To: stp@create.ucsb.edu
Cc: squeak@create.ucsb.edu
In-Reply-To: <9612031433.AA07774@tango.create.ucsb.edu>
Subject: Re: Format for Squeak Mailing List--mail/news/web?
At 1:34 AM -0500 12/3/96, Stephen Travis Pope wrote:
>Hello all,
>
>I'd just like to discuss the format of this discussion for a minute. Each of
>the three main media for distributed asyncronous communication --email,
>netnoise, and the WorldWierdWeb--have advantages and disadvantages.
>
>In the past couple of weeks, I've been looking into several software packages
>(e.g., WWWboard and HyperNews) that merge some of the best features of news
>groups and web pages. I've been hoping to find a package that can take a mail
>archive file (such as ours) and turn it into a threaded outline such as in
>Netscape News or other tools.
>
>Just for my information, how many readers have no Web access, or vastly prefer
>the e-mailing list to a news group? How many of you use the indexed Web page I
>set up?
>
>Does anyone know of a package that would take our mail archive and make a
>threaded web page a la HyperNews/WWWboard (and allow readers to post to the
>list via mail or news)?
>
>stp
>
> Stephen Travis Pope, Center for Research in Electronic Art Technology
> (CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
> Editor--Computer Music Journal, MIT Press
> stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
I like email lists because you don't get all the wonderful posts:
EARN $1,000,000 IN THE NEXT 5 DAYS!!!!!!!!!!!!!!!!!!!!!
SUZY SEXPOT SHOWS ALL.....
<hatedGroup> EAT <hatedFoodSubstance> ON <religiousDay>
SEND 200,000 MAIL MESSAGES AN HOUR AND NOT TIE UP YOUR MACHINE!
<poorJerk> HAS OFFENDED THE RIGHT REV COLIN THE 3RD, RANT RAVE REVENGE
At:
http://iamwww.unibe.ch:80/~fcglib/WWW/OnlineDoku/archive/DesignPatterns/
there seems to be a web page which contains an archive of the Design
Patterns mail list. Don't know how they did it. An advantage is public
access to the discussion without public posting. However, there is
something more private about a mail list because it is not open to the
world of casual browsers. People can be more open, more able to be creative
or to praise or criticize without being as subject to misunderstanding or
attack.
Dave
BTW, I often keep Netscape up all day, along with a mail server and a mail
reader. It's only 15 meg of my 96. (IE, I have no problem with memory and
still prefer email.)
_______________________________
David N. Smith
dnsmith@watson.ibm.com
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author
and not of his employer.
Date: 96 Dec 04 12:46:13 pm
From: TECHIN.A.KANG@sprint.sprint.com
To: squeak@create.ucsb.edu
Subject: quick fix on resize window problem
There is a bug in the Win32 VM regarding to main window resizing.
Here is the problem:
Function reverse_image_bytes() will cause "memory access violation" if
argument x0 > x1.
You can temporarily fix this problem by inserting a "if (x0 > x1)" statement
to exit function right away. However, this fix didn't give you the window
size you want. You need to resize to the dimension you want and then "save
and quit squeak". Next time you get the window size to play.
Date: 96 Dec 04 10:12:00 pm
From: Dan Ingalls <DanI@wdi.disney.com>
To: squeak@create.ucsb.edu
Subject: How are we doing?
Please take a few minutes to answer the following questions (to me; I'll
distribute the results in a few days). If you edit your answers into this
text it will be easier for me to digest.
What do you like best about Squeak?
Openness, maleability/portability because of being written mostly in
itself, something else?
What do you like least about Squeak?
Performance, support, bugs, something else?
For what do you mainly use Squeak?
Teaching, recreational programming, big business, adventure games, rocket
design, something else?
How many hours per week do you spend working on or using Squeak?
What direction(s) would you most like to see Squeak go?
Higher performance, pluggable host UIF, dynamite game machine kernel,
multimedia playground, something else?
How do you feel about the Squeak Team process?
What are we doing right that you'd like to see more of?
What are we doing wrong that you'd like to see done differently or dropped?
What are we not doing at all that you think we should do?
We find it hard to take full advantage of contributions to Squeak from the
larger community. This is partly because we simply don't have time to try
everything out. Please list your "Top N" recommendations for inclusion in
future Squeak releases. [Rate as 10=really good/got to have it, down to
0=a real mistake to include it]. Giving reasons always helps (smaller,
faster, does more)
Similarly there is some decent code in the Smalltalk Archive at UIUC.
Would you strongly advocate the inclusion of any of these in future Squeak
releases? Again, please list with you rating.
Any other things you would like to say?
Who would like to build a simple high-preformance VM for Squeak?
Is there any way we can help?
Anything else you would contribute if we could help you do it?
Upcoming releases, for your info:
We are working internally on 1.18 to be released around 12/15. It will
feature:
Fixes to formatter, simulator and a few other things
Simple image windows
Ability to throw away source files and still get good browsing
(saves temp names compactly)
Better control over temporary variable usage
Sundry performance and portability improvements
We hope to have another release by the end of the year, with the focus being:
Sockets
Perhaps an experimental finalization and/or weak pointer facility
An attempt to pare down some oe present code bloat
Not long after that, we'll probably do 1.2 which will be an attempt to lump
together a
number of improvements that require changes to the image format.
Thanks for your time.
- Dan, for the Squeak Team
Date: 96 Dec 05 12:04:28 am
From: John Maloney <johnm@wdi.disney.com>
To: stp@create.ucsb.edu (Stephen Travis Pope)
Cc: squeak@create.ucsb.edu
Subject: Re: Format for Squeak Mailing List--mail/news/web?
Re:
Just for my information, how many readers have no Web access,
or vastly prefer the e-mailing list to a news group? How many
of you use the indexed Web page I set up?
I prefer email. I'd only poll the Web page once every week or
two. With email, I see stuff immediately.
I've used your indexed Web page once and expect to use it
more in the future. Having it there allows me to delete things,
since I know where to find them again if I need to.
Bottom line: both email and the archive are useful.
-- John
Date: 96 Dec 05 6:28:52 am
From: stp (Stephen Travis Pope)
To: squeak@create.ucsb.edu
Subject: New Goodies...
Here's this week's goodies. See the file
ftp://ftp.create.ucsb.edu/pub/Smalltalk/Squeak/goodies/00README
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Color-depth.st
This is the 'depth' method for colors.
AUTHOR Stephen T. Pope (stp@create.ucsb.edu)
VERSION 1.0
PREREQUISITES none
DISTRIBUTION world
DATE December 5, 1996
display-compatibility.st
These are for backward compatibility.
AUTHOR Stephen T. Pope (stp@create.ucsb.edu)
VERSION 1.0
PREREQUISITES none
DISTRIBUTION world
DATE December 5, 1996
View-addSubViewinborderWidth.st
This is for compatibility...
AUTHOR Stephen T. Pope (stp@create.ucsb.edu)
VERSION 1.0
PREREQUISITES none
DISTRIBUTION world
DATE December 5, 1996
CompiledMethod-needsFrameSize.st
This is a small 'fix' for large methods.
AUTHOR Stephen T. Pope (stp@create.ucsb.edu)
VERSION 1.0
PREREQUISITES none
DISTRIBUTION world
DATE December 5, 1996
TextEmphasis-storeOn.st
This code makes storing texts a bit more compact by storing the emphasis and font changes in a 'native' form.
AUTHOR Stephen T. Pope (stp@create.ucsb.edu)
VERSION 1.0
PREREQUISITES none
DISTRIBUTION world
DATE December 5, 1996
UnixFileDirectory-filenames-old.st
This fixes a bug whereby file names were shortened to 32 characters even on UNIX.
AUTHOR Stephen T. Pope (stp@create.ucsb.edu)
VERSION 1.0
PREREQUISITES none
DISTRIBUTION world
DATE December 5, 1996
SystemOrganizer-fileOutCategoryon.st
This removes a class from the change list when it's filed out..
AUTHOR Stephen T. Pope (stp@create.ucsb.edu)
VERSION 1.0
PREREQUISITES none
DISTRIBUTION world
DATE December 5, 1996
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Stephen Travis Pope, Center for Research in Electronic Art Technology
(CREATE), Department of Music, U. of California, Santa Barbara (UCSB)
Editor--Computer Music Journal, MIT Press
stp@create.ucsb.edu, http://www.create.ucsb.edu/~stp/
Date: 96 Dec 05 7:07:10 am
From: Jecel Assumpcao Jr <jecel@lsi.usp.br>
To: squeak@create.ucsb.edu
Subject: dynamic compilation
I just got on this list and was reading the november
archive. Several people seemed to think that better
performance in the form of dynamic compilation would
come at too great a cost to be considered for Squeak.
I'd like to comment on two of these costs.
1. Memory
Native code takes up much more memory than bytecodes.
But there is no need to compile everything: 20% of
the code is probably responsible for 80% of the
execution time. Compile that and interpret everything
else. The latest Self has two compilers and uses the
simple one for eveything then recompiles with the
better (but slower) one only when a usage counter
indicates that the method is in the critical path
of the code.
The fact that Self is a memory hog has made most people
dislike such adaptive compilation. But let's look at
the details. Most of the memory is taken up by code
generated by the simple compiler. Replacing that
with an interpreter would result in enormous savings.
A single bytecode method is compiled into many
"customized" native codes, one for each inherited
use of the method. This is fundamental in Self where
everything is done as messages to self. Smalltalk
uses specialized bytecodes for these things and
wouldn't gain much with customization. This is
another tremendous memory gain. It is also important
to note that Self uses bytes or words for single bit
flags in order to gain the maximum possible speed.
Compact these flags and you will gain memory while
loosing a little performance.
2. Per CPU Code Generator
For every different CPU you support you have to write
a separate code generator. First of all, I don't
think you need to support as many CPUs as, for
example, gcc. I think that if it is done in a nice
OO way, with generous use of inheritance and such
then creating generators for the second CPU, third
and so on, will be much simpler than it seems.
One great advantage of a native code generator is
that it would be used for generating a new VM *and*
normally during runtime. The current C translator
sits uselessly in the image most of the time. Another
thing is that you can do all kinds of neat things
with the stack in assembly (some of which have already
been suggested here) that are a major headache to do
in C.
--
-----=============( Jecel Mattos de Assumpcao Jr )===========-----
http://www.lsi.usp.br/~jecel/merlin.html | mailto:jecel@lsi.usp.br
Date: 96 Dec 05 9:21:17 am
From: John Maloney <johnm@wdi.disney.com>
To: Jecel Assumpcao Jr <jecel@lsi.usp.br>
Cc: squeak@create.ucsb.edu, John Maloney <johnm@wdi.disney.com>
Subject: Re: dynamic compilation
Jecel,
I agree with your comments on Self's VM technology costs. In fact,
the Animorphic Smalltalk and Java VM's show that this technology
can be made to work in a small memory footprint (they use a hybrid
interpreter/compiler scheme). It's quite a lovely system. See:
www.animorphic.com
for details. A number of ex-Self folks worked on it (esp. Lars and Urs).
It is, however, a considerably more complex system and not nearly
as portable as a simple interpreter.
-- John
Date: 96 Dec 05 9:31:19 pm
From: Patrick Logan <plogan@teleport.com>
To: jecel@lsi.usp.br
Cc: squeak@create.ucsb.edu
In-Reply-To: <32A6D329.18CA4302@lsi.usp.br> (message from Jecel Assumpcao Jr
on Thu, 05 Dec 1996 11:50:33 -0200)
Subject: Re: dynamic compilation
> ...Self...
> One great advantage of a native code generator is that it would
> be used for generating a new VM *and* normally during
> runtime. The current C translator sits uselessly in the image
> most of the time. Another thing is that you can do all kinds of
> neat things with the stack in assembly (some of which have
> already been suggested here) that are a major headache to do in
> C.
Ths is an off-the-wall suggestion, especially since I am more of a
lurker than a contributor and will most likely remain so for a long
time... but anyway...
One can do neat things in native code, but native code is not portable
and native code requires a lot of knowledge about the native machines.
Do the Sqeuak team and/or Squeak fans really want to be bit twiddlers
rather than Smalltalkers?
OTOH, one cannot do neat things in C. Well, not unless you are Henry
Baker. (See his Cheney-on-the-MTA approach for compiling to C. A
really neat way of handling the stack *and* the GC!)
On the other hand, I can think of more than a handful of higher-level
languages that have *already* been freely ported efficiently to
several machines. So why not compile Squeak to a higher-level
language? Some examples: Modula-3, Standard ML of New Jersey (SML/NJ),
and various Scheme compilers (C-Gambit, Bigloo, Stalin). Plus if
Squeak were to compile to Scheme or SML/NJ then closures, exception
handling, and one-shot or full continuations could be really easy to
implement. May as well take advantage of the high-level compiler
writers who already have working code.
Just my $0.02 from left field.
-Patrick Logan
Date: 96 Dec 06 1:01:30 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: display updating (again^2)
Just for the record: desktopColor.st at
<http://ftp.tuwien.ac.at/~go/Squeak> is at version 1.3. Updating (without
cache) should be a bit faster and less of a hack now.
Georg
----
Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum
phon:(++43-1) 58801 - 5848
mail:gollmann@edvz.tuwien.ac.at
http://ftp.tuwien.ac.at/~go/Gollmann.html
Date: 96 Dec 06 11:51:58 am
From: Jecel Assumpcao Jr <jecel@lsi.usp.br>
To: Patrick Logan <plogan@teleport.com>
Cc: squeak@create.ucsb.edu
Subject: Re: dynamic compilation
Patrick Logan wrote:
> > [my good points about code generation]
>
> Ths is an off-the-wall suggestion, especially since I am more of a
> lurker than a contributor and will most likely remain so for a long
> time... but anyway...
>
> One can do neat things in native code, but native code is not portable
> and native code requires a lot of knowledge about the native machines.
True and true! I said that there were some advantages to it,
not that it should be used in Squeak.
> Do the Sqeuak team and/or Squeak fans really want to be bit twiddlers
> rather than Smalltalkers?
I don't think so.
> OTOH, one cannot do neat things in C. Well, not unless you are Henry
> Baker. (See his Cheney-on-the-MTA approach for compiling to C. A
> really neat way of handling the stack *and* the GC!)
That is a very intersting paper. It is available on the web
as ftp://ftp.netcom.com/pub/hb/hbaker/CheneyMTA.html
I am not sure about how efficient his system really is, since
he can't optimize away as many continuations as most other
methods do.
> On the other hand, I can think of more than a handful of higher-level
> languages that have *already* been freely ported efficiently to
> several machines. So why not compile Squeak to a higher-level
> language? Some examples: Modula-3, Standard ML of New Jersey (SML/NJ),
> and various Scheme compilers (C-Gambit, Bigloo, Stalin). Plus if
> Squeak were to compile to Scheme or SML/NJ then closures, exception
> handling, and one-shot or full continuations could be really easy to
> implement. May as well take advantage of the high-level compiler
> writers who already have working code.
I assume that you are talking about dynamically compiling
Smalltalk to one of those languages at runtime - since
Squeak already does static translation to C and there is
nothing to be gained to moving to another language.
I agree that one possibility would be to generate C code
at runtime, call the compiler on that code and then load
that code back into the system (via a DLL or something).
The time and memory overhead of loading the C compiler
would be very great, but the amount of code to be
compiled would be so small that this might result in a
usable system. See how the RScheme people do it
http://www.tkg.com/people/donovan/proj/rs/rscheme.html
-- Jecel
Date: 96 Dec 06 11:52:09 am
From: Jecel Assumpcao Jr <jecel@lsi.usp.br>
To: squeak@create.ucsb.edu
Subject: inline caches
In his dissertation, Urs Hoelzle speculates on various ways
on which an efficient Self interpreter could be constructed.
On page 32, he writes:
Alternatively, the interpreter could just add inline
caching to the straightforward interpreter by adding
one pointer per send byte code to cache the method
last invoked by that send; each method would also
cache the last receiver type. Similar organizations
have been used for Smalltalk interpreters. Since most
bytecodes are sends, this approach would require
roughly one word per byte code.
In Self all bytecodes are exactly one byte in length
and most are sends. In this case it might make sense
to create a pointer array as large as the bytecodes
to associate each one with a non-inline inline (!)
cache. I can't think of any way to compress this
pointer array taking into account non send bytecodes
that wouldn't have a great performance penalty.
Anyway, I did some quick and dirty statistics on Squeak
and found (as I expected) that most bytecodes aren't
sends (see table 3 below). Besides, many bytecodes are
more than one byte in length.
I also looked at how many literals in the literal arrays
are used as message selectors (table 1), and found that
most are. It seems to me that we could create a shadow
array for the literal array to store pointers used as
pseudo inline caches without having too much space
wasted.
Of course, this idea would have one cache per selector
in a method instead of per call site. Table 3 shows
that there is actually little difference between the
two (even less than the table seems to indicate, as
different call sites with the same selector *within*
a method are more prone to have similar type profiles).
Each pointer in this shadow array could either pointer
directly to the destination method (or some header
structure) or could point to a Self-style PIC. The
latter option probably doesn't make sense in a system
without customization.
If some usage counts are kept for each method, then it
might be best to only allocate these shadow arrays
for frequently used methods, and to flush them if
a method stops being called for a long time.
TABLE 1
Percentage of Literals that are Message Selectors
-------------------------------------------------
Percentage Number Cumulative Frequency
0% 445 6.9%
10% 56 7.7%
20% 123 9.6%
30% 210 12.8%
40% 180 15.6%
50% 1058 31.9%
60% 851 45.0%
70% 625 54.6%
80% 535 62.9%
90% 89 64.2%
100% 2324 100.0%
TABLE 2
Percentage of Unique Message Selectors
-------------------------------------------------
Percentage Number Cumulative Frequency
0% 1 0.015%
10% 10 0.17%
20% 58 1.1%
30% 110 2.8%
40% 147 5.0%
50% 350 10.4%
60% 455 17.4%
70% 477 24.8%
80% 651 34.8%
90% 139 37.0%
100% 4093 100.0%
TABLE 3
Percentage of Bytecodes that are Message Sends
-------------------------------------------------
Percentage Number Cumulative Frequency
0% 628 8.8%
10% 521 16.2%
20% 3151 60.5%
30% 2064 89.5%
40% 520 96.9%
50% 207 99.8%
60% 13 99.96%
70% 3 100.0%
80% 0 100.0%
90% 0 100.0%
100% 0 100.0%
LISTING 1 - code to generate raw data for table 1
| d r cl |
d _ Array new: 11.
1 to: 11 do: [ :i | d at: i put: 0 ].
CompiledMethod allInstances do: [ :c |
cl _ c literals.
cl size > 0 ifTrue: [
r _ ((10*((c messages select: [ :e | cl includes: e ]) size))
// (cl size)) + 1.
d at: r put: ((d at: r) + 1)
]
].
^ d
LISTING 2 - code to generate raw data for tables 2 and 3
| scanner aSet aBag total a1 a2 r1 r2 |
a1 _ Array new: 11 withAll: 0.
a2 _ Array new: 11 withAll: 0.
CompiledMethod allInstances do: [ :cm |
total _ 0.
aSet _ Set new.
aBag _ Bag new.
scanner _ InstructionStream on: cm.
scanner scanFor: [ :byteCode |
total _ total + 1.
scanner addSelectorTo: aSet.
scanner addSelectorTo: aBag.
false "keep scanning until finished"
].
aBag size > 0 ifTrue: [
r1 _ ((10*(aSet size)) // aBag size) + 1.
a1 at: r1 put: ((a1 at: r1) + 1)
].
total > 0 ifTrue: [
r2 _ ((10*(aBag size)) // total) + 1.
a2 at: r2 put: ((a2 at: r2) + 1)
]
].
^ a1 printString, ' ', a2 printString
OBS: listing 1 avoids counting special selector sends
while listing 2 does not.
--
-----=============( Jecel Mattos de Assumpcao Jr )===========-----
http://www.lsi.usp.br/~jecel/merlin.html | mailto:jecel@lsi.usp.br
Date: 96 Dec 06 12:30:58 pm
From: james@clyde.as.utexas.edu (James McCartney)
To: Jecel Assumpcao Jr <jecel@lsi.usp.br>, squeak@create.ucsb.edu
Subject: Re: inline caches
At 3:24 PM 12/6/96, Jecel Assumpcao Jr wrote:
>most are. It seems to me that we could create a shadow
>array for the literal array to store pointers used as
>pseudo inline caches without having too much space
>wasted.
I've wondered whether polymorphic inline caches are really more space
efficient than just flattening the method lookup hash table for a class
so that it includes all its superclasses' selectors. The method hash would
always hit without looking up the tree. This would be a space overhead
equivalent to C++'s vtables. That's a lot, but don't inline caches use up
quite a bit of space as well?
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Dec 06 4:01:48 pm
From: Andreas Raab <raab@isg_nw.cs.Uni-Magdeburg.DE>
To: squeak@create.ucsb.edu
Subject: FileDirectory >> includesKey:
Hi,
just found that in FileDirectory>>includesKey: the Mac's path name
delimiter ':' is hard coded, which is rather unfortunate on
other platforms :-)
Here is a fix:
------------------------------------------------------------------
'From Squeak 1.13 of October 17, 1996 on 6 December 1996 at 8:57:21 pm'!
!FileDirectory methodsFor: 'dictionary access'!
includesKey:aString
"Answer whether the receiver includes an element of the given name."
"Note: aString may designate a file local to this directory, or it may be a full path name. Try both."
^ (StandardFileStream isAFileNamed: pathName, (String with: self pathNameDelimiter),aString) or:
[StandardFileStream isAFileNamed: aString]! !
-------------------------------------------------------------------
- Andreas
--
Linear algebra is your friend - Trigonometry is your enemy.
+===== Andreas Raab ============= (raab@isg.cs.uni-magdeburg.de) =====+
I Department of Simulation and Graphics Phone: +49 391 671 8065 I
I University of Magdeburg, Germany Fax: +49 391 671 1164 I
+=============< http://simsrv.cs.uni-magdeburg.de/~raab >=============+
Date: 96 Dec 06 4:03:03 pm
From: Andreas Raab <raab@isg_nw.cs.Uni-Magdeburg.DE>
To: squeak@create.ucsb.edu
Subject: Windows VM update
Hi,
I've put an updated version of the Windows NT port for Squeak on
http://simsrv.cs.uni-magdeburg.de/~raab/squeak/
and
ftp://simsrv.cs.uni-magdeburg.de/pub/Smalltalk/free/squeak/win32
(not available before next week - our ftp admin is out for the weekend)
The major changes are:
* Fixed non US keyboard support
(the right alt-key did not work correctly)
* Fixed window size problem on startup
(the window was sometimes larger than the screen)
* Fixed palette creation bug
(cursor could not be seen in some windows)
* Fixed GPF when resizing the main window
* Added character mapping for umlauts etc.
* Slight speed up when drawing several small areas
* Error messages are now printed when the squeak session ends
Bye,
Andreas
--
Linear algebra is your friend - Trigonometry is your enemy.
+===== Andreas Raab ============= (raab@isg.cs.uni-magdeburg.de) =====+
I Department of Simulation and Graphics Phone: +49 391 671 8065 I
I University of Magdeburg, Germany Fax: +49 391 671 1164 I
+=============< http://simsrv.cs.uni-magdeburg.de/~raab >=============+
Date: 96 Dec 06 4:03:34 pm
From: Andreas Raab <raab@isg_nw.cs.Uni-Magdeburg.DE>
To: squeak@create.ucsb.edu
Subject: Window VM update (Correction)
Oops, the right ftp location is
ftp://ftp.cs.uni-magdeburg.de/pub/Smalltalk/free/squeak/win32
^^^
- Andreas
--
Linear algebra is your friend - Trigonometry is your enemy.
+===== Andreas Raab ============= (raab@isg.cs.uni-magdeburg.de) =====+
I Department of Simulation and Graphics Phone: +49 391 671 8065 I
I University of Magdeburg, Germany Fax: +49 391 671 1164 I
+=============< http://simsrv.cs.uni-magdeburg.de/~raab >=============+
Date: 96 Dec 06 4:13:09 pm
From: Tim Rowledge <rowledge@interval.com>
To: Andreas Raab <raab@isg_nw.cs.Uni-Magdeburg.DE>
Cc: Squeak mailinglist <squeak@create.ucsb.edu>
In-Reply-To: <114C4623B4F@isg_nw.cs.uni-magdeburg.de>
Subject: Re: FileDirectory >> includesKey:
On Fri 06 Dec, Andreas Raab wrote:
> Hi,
>
> just found that in FileDirectory>>includesKey: the Mac's path name
> delimiter ':' is hard coded, which is rather unfortunate on
> other platforms :-)
>
I suspect a slightly better fix is
!FileDirectory methodsFor: 'dictionary access'!
includesKey:aString
"Answer whether the receiver includes an element of the given name."
"Note: aString may designate a file local to this directory, or it may be a full path name."
^ (StandardFileStream isAFileNamed:(self fullNameFor: aString)! !
...since it doesn't need to do two checks and will do any and all
name chacking appropriate to the platform.
--
Tim Rowledge: rowledge@interval.com (w) +1 (415) 354-3627 (w)
tim@sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>
Date: 96 Dec 06 6:53:45 pm
From: CarlGWatts@AppliedThought.com (Carl G. Watts)
To: DanI@WDI.Disney.com, Squeak@create.ucsb.edu
Subject: Bugs in Behavior new and new:
--============_-1362194980==_============
Content-Type: text/plain; charset="us-ascii"
Dan,
In Behavior new, it shouldn't retry by doing 'self new' because some subclasses override 'new' to do something different (for example Set). I got into problems because of this.
If you try to instantiate 'Set new: 600' and the first attempt at the primitive fails (for low space say) and you proceed, then 'self new' ends up calling the 'new' in Set which answers a 'Set new: 4'
To retry it should do 'self basicNew' since basicNew is not supposed to be overridden by subclasses (although the comment should say that).
Similarly with new:
Please find attached new versions of the four methods in Behavior...
Keep on Squeakin'
Carl Watts
Applied Thought
http://AppliedThought.com/
--============_-1362194980==_============
Content-Type: application/mac-binhex40; name="Behavior-new.st"
Content-Disposition: attachment; filename="Behavior-new.st"
(This file must be converted with BinHex 4.0)
:$d*PD'&fD@pb,@jPGbjcG!"849K88LTMD!%!!!!(a!!!!!"mFLG'FQpY)&0aG@9
KDb!a,M%c)'pQ)%pMG'pLCA)J-6FX)$%j16BJEfiJ0L"%C@0PE@*PFL!a16Nf)'&
d)$Bk0$Jk0$FJF'dR)3d0$5&#C@KKGQP[FL"YCA4SEf4c4Qpb1L!RD@jcG'&ZBf8
JBh*PBA4TEfiR)3eLBA0TBdjPG`d*)N&ZFhGPFL"K)'jPGb"TER0dB@jMC5"[CL"
dD'8JFQ9MC@PfCA)J+(GSD@0S)'Pc)'%JBfaKFh-T)(GTG'JJEQmJD@jNCAKKBQa
P)(CKFQPKBQaPFbiJ4Q&TE#"TCL"dD'8JBfaKFh-JDA-JD@jNCAKKBQaP,L)0#5*
&Fh0PER4TB@`J8(*TE@PdDACP,L"6C@8J6f*UC@0d)'4[Bh9YC@jdBA4TEfiJGfK
KG%Pc39"bD@eTG'PfC5i0#8j29%8k)#"8D'Pc)'ePG'K[C#"cD'peE'3JEQpd)'*
P)'pfCA*bD@4NC@iJD@iJB@jj)(0eBQ0XBA0cCA-Z)Jd0#6a`FQPYDA4TGQ8k)$F
`2Jd*Ff9XCL"TFeCKFQPKBQaP)'PQ9(*eC6SJ@b"H)(0PE'BJBQ&cD@01CAFk)$!
JA5i0#5*cF'&MC5"YGA0d)'*P)'a[Gb)0#90YB@aXG'&XDb"cD@GZB@a-EhG6F'&
MC5i0#9jcC@aQ)'*KFfPM6Q9h)#!LFQ9dFRNJD@BJGA0PFL"`FQpMC@9NFb)0)3e
LBA0TBdjPGcSJB@j*ER4PCf9b)!d*)N&ZFhGPFL"K)'jPGb"TER0dB@jMC5"[CL"
dD'8JFQ9MC@PfCA)J+(GSD@0S)'Pc)'%JBfaKFh-T)(GTG'JJG'KP)'jeE@*PFL"
[CL"TEQ4PH'&LE'8JGQ&bD@&LE'9c)(0`C@0TCQPPC#"LH5"dD'8JBA*RG@ePER3
X)'&Z5@jdC@GPFLiJ4Q&TE#"TCL"dD'8JBfaKFh-JDA-JEQpd)'PZC'9iB@*XC5"
[FL"TCL"dD'8JBA*RG@ePER3JDA-JEQpd)'%JF'pcDA4TGQ8J5@jdC@GPFLiL$3N
L4A0cC@jdD@&X)&"bD@eTG'PfC5iJ8f9P)%pLDQ9MG#"NEf0eE@9ZG'&dD@pZ)(G
SBA4*Fd&3FQPYDA4TGQ8Z$3P16e4&1L!J9'KTFb"YCA4SEf3JFfK[G@aN)'j[G#"
LC5"[GQ9bFQPNC'9Z)'PZ)'&ZH5"cG@*ME'&cFf9c,L)0$3NmF(*TE@PdDACP1L!
h-6i0#5KKENPZG'9RCA)JDA0*ER4PCf9b)'&ZC$SJ@f&Z5@jdC@GPFL!q25!`A5N
JD@C8FR9P1L"E$3N*)Q&bCb"[Df&j1b"cF'&MC5"YGA0d)'*P)'a[Gb)0#3P6E@&
XE(4KE'XJFfPREQ&X6'ph8h"KBf8Z$3N*AL"cC@aQ)'*KFfPM6Q9h1L"KENPZG'9
RCA)J)#*bCA4bH5"TCL"eFf9b)("bEf0PC@4c)Jd*A5i0#A0PE'BJF(*TE@PdDAC
P4Q&TE'9N)3eZCAF0#5*"ER0hCA)JB5"ZCAFJD@jcG'&ZBf8JEfBJG'KP)(*PBf9
TGQ9b)#KhD'PMD#"TFb"K)'0XBA0c+5"hDA4S)'j[)'PZC'9iB@*XC5"fBA*TB@*
XCA-Z)%CKD@`JD@BJG'KP)'0XBA0c)'Pc)'PZC'9iB@*XC5iL$3NL4A0cC@jdD@&
X)&"bD@eTG'PfC5iJ8f9P)%pLDQ9MG#"NEf0eE@9ZG'&dD@pZ)(GSBA4*Fd&3FQP
YDA4TGQ8Z)Jd0#6a`FQPYDA4TGQ8k)$F`2Jd*Ff9XCL"TFeCKFQPKBQaP)'PQ9(*
eC6SJ@ejcC@aQ)'*KFfPM6Q9h1L!`A5i0#5*cF'&MC5"YGA0d)'*P)'a[Gb)0#90
YB@aXG'&XDb"cD@GZB@a-EhG6F'&MC5i0#9jcC@aQ)'*KFfPM6Q9h)#!LFQ9dFRN
JD@BJGA0PFL"`FQpMC@9NFb)0)3eZCAFk)'&Z5@jdC@GPFL!0#5*"ER0hCA)JB5"
ZCAFJD@jcG'&ZBf8JEfBJG'KP)(*PBf9TGQ9b)#KhD'PMD#"TFb"K)'0XBA0c+5"
hDA4S)(4SC5"ZG@eLCA)JEfBJD@jNCAKKBQaP)(CKFQPKBQaPFb"cF'9MD@CTC@3
JBRNJG'KP)'&bCh9YC@jd,#"KENPZG'9RCA)Z)%CKD@`JD@BJG'KP)'0XBA0c)'P
c)'j[G#"TEQ4PH'&LE'8JEh)JD@BJG'KP)'&bCh9YC@jd)'Pc)'j[G#"K)("[FfP
dDACP)%PZG'9RCA)Z)Jd*)N9cFf9ZG'PKE#"3FQPYDA4TGQ8Z)&0PC5"2BQTPBh3
JC'pMG@ePER4KG'P[EL"hD'&d5A0"8(*TE@PdDACP,L)0$3NmF(*TE@PdDACP1L!
h-6i0#5KKENPZG'9RCA)JDA0*ER4PCf9b)'&ZC$SJ@f&Z5@jdC@GPFL!q25!`A5N
JD@C8FR9P1L"E$3N*)Q&bCb"[Df&j1b"cF'&MC5"YGA0d)'*P)'a[Gb)0#3P6E@&
XE(4KE'XJFfPREQ&X6'ph8h"KBf8Z$3N*)R*PG(*j)'PQ)(9cCA)JF(*[Bf9PC(-
L$3N*AR0PE'BJBQ&cD@01CAFk)'&Z5@jdC@GPFPdZ$3PcC@aQ)("bD@eTG'PfC8C
KD@aPC#%J)3d0--S!!!:
--============_-1362194980==_============--
Date: 96 Dec 06 7:03:26 pm
From: Jecel Assumpcao Jr <jecel@lsi.usp.br>
To: James McCartney <james@clyde.as.utexas.edu>
Cc: squeak@create.ucsb.edu
Subject: Re: inline caches
James McCartney wrote:
> I've wondered whether polymorphic inline caches are really more space
> efficient than just flattening the method lookup hash table for a class
> so that it includes all its superclasses' selectors. The method hash would
> always hit without looking up the tree. This would be a space overhead
> equivalent to C++'s vtables. That's a lot, but don't inline caches use up
> quite a bit of space as well?
Take a look at:
"Message Dispatch on Pipelined Processors"
Karel Driesen, Urs Hoelzle and Jan Vitek
Proceedings of ECOOP 95, pages 253-282
Sorry, I don't have a URL for it, but you can get it from UCSB's
site somewhere.
Here is the space overhead data they give for the two methods
applied to the Smalltalk VisualWorks 1.0 class hierarchy:
system code cost data cost total
---------------------------------------------------------
PIC 477KB 231KB 708KB
VTBL 274KB 696KB 970KB
These are just estimates. The surprising result for VTBLS
is due to the fact that a class defines a method for
every 20 it inherits (on average).
Modern CPUs are not at all good in indirect jumps/calls
relative to direct (predictable) ones, so the PIC gets
a speed advatange there.
Your proposal would have an additional speed penalty due to
hashing, and would need twice the data space of normal
VTBLs (which don't need to store selectors explicitly).
-- Jecel
Date: 96 Dec 06 11:34:33 pm
From: james@clyde.as.utexas.edu (James McCartney)
To: Jecel Assumpcao Jr <jecel@lsi.usp.br>
Cc: squeak@create.ucsb.edu
Subject: Re: inline caches
At 11:48 PM 12/6/96, Jecel Assumpcao Jr wrote:
>Modern CPUs are not at all good in indirect jumps/calls
>relative to direct (predictable) ones, so the PIC gets
>a speed advatange there.
I don't understand this bit here. If we're talking Squeak which
doesn't compile, then any caching, PIC, VTBL or whatever is an
indirect call so I see no advantage of one over the other.
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Dec 06 11:40:21 pm
From: james@clyde.as.utexas.edu (James McCartney)
To: Jecel Assumpcao Jr <jecel@lsi.usp.br>
Cc: squeak@create.ucsb.edu
Subject: Re: inline caches
>Your proposal would have an additional speed penalty due to
>hashing, and would need twice the data space of normal
>VTBLs (which don't need to store selectors explicitly).
That is the method I'm using for a real time VM I'm writing
because I don't want to ever miss. Any other methods you know
of that guarantee a fixed lookup time?
Straight VTBLs are not possible because the selectors are not
serializable.
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Dec 08 9:10:00 am
From: "David Robinson" <davidr@ee.mcgill.ca>
To: <squeak@create.ucsb.edu>
Subject: Bytecode list?
I am working my way thru the C code for the Win32 VM,
and I was wondering if anyone could post the bytecode
table (the number and the name and function of the bytecode)
thanks
Date: 96 Dec 08 10:12:40 am
From: Dan Ingalls <DanI@wdi.disney.com>
To: "David Robinson" <davidr@ee.mcgill.ca>
Cc: squeak@create.ucsb.edu
In-Reply-To: <199612081712.MAA01523@aries.EE.McGill.CA>
Subject: Re: Bytecode list?
David -
I don't have such a table handy, but the code for
Interpreter class initializeBytecodeTable
is exactly such a table without comments, and you can then use
Smalltalk browseAllImplementorsOf:
to see what each one does.
[If your Squeak doesn't yet work, then use a text editor to search the
changes file for this method].
Another slant on this can be found in
InstructionStream interpretNextInstructionFor:,
but I think the first reference will do you the most good.
Have fun
- Dan
>I am working my way thru the C code for the Win32 VM,
>and I was wondering if anyone could post the bytecode
>table (the number and the name and function of the bytecode)
>
>thanks
Date: 96 Dec 08 12:48:00 pm
From: Jecel Assumpcao Jr <jecel@lsi.usp.br>
To: James McCartney <james@clyde.as.utexas.edu>
Cc: squeak@create.ucsb.edu
Subject: Re: inline caches
> >Modern CPUs are not at all good in indirect jumps/calls
> >relative to direct (predictable) ones, so the PIC gets
> >a speed advatange there.
>
> I don't understand this bit here. If we're talking Squeak which
> doesn't compile, then any caching, PIC, VTBL or whatever is an
> indirect call so I see no advantage of one over the other.
"Real" PICs, those with native code, offer a good speed
advantage on modern processors and are simple enough to
generate that they might be worth including even on a
system that doesn't otherwise generate native code. I
am not saying it would be a good idea, but that it is
an option to be considered.
> >Your proposal would have an additional speed penalty due to
> >hashing, and would need twice the data space of normal
> >VTBLs (which don't need to store selectors explicitly).
>
> That is the method I'm using for a real time VM I'm writing
> because I don't want to ever miss. Any other methods you know
> of that guarantee a fixed lookup time?
It depends on your needs. If you can tolerate some complication
during the programming cycle in order to gain performance
at runtime, you might consider the "Compact Selector-Indexed
Dispatch Table". It is usually associated with static systems,
but it is easy for me to see how to make table management
incremental in order for it to work with systems like Smalltalk.
see http://www.cs.ucsb.edu/oocsb/papers/oopsla93.html
and http://www.cs.ucsb.edu/oocsb/papers/TRCS95-05.html
> Straight VTBLs are not possible because the selectors are not
> serializable.
Not normally, but you could do it as part of extracting the
application for deployment.
-- Jecel
Date: 96 Dec 08 2:57:16 pm
From: james@clyde.as.utexas.edu (James McCartney)
To: Jecel Assumpcao Jr <jecel@lsi.usp.br>
Cc: squeak@create.ucsb.edu
Subject: Re: inline caches
At 5:33 PM 12/8/96, Jecel Assumpcao Jr wrote:
>It depends on your needs. If you can tolerate some complication
>during the programming cycle in order to gain performance
>at runtime, you might consider the "Compact Selector-Indexed
>Dispatch Table". It is usually associated with static systems,
>but it is easy for me to see how to make table management
>incremental in order for it to work with systems like Smalltalk.
I have read this paper and it wasn't immediately clear how to make
it incremental without a big wait each time a selector is added to
the system.
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Dec 08 6:44:49 pm
From: james@clyde.as.utexas.edu (James McCartney)
To: Jecel Assumpcao Jr <jecel@lsi.usp.br>
Cc: squeak@create.ucsb.edu
Subject: Re: inline caches
At 4:58 PM 12/8/96, James McCartney wrote:
>At 5:33 PM 12/8/96, Jecel Assumpcao Jr wrote:
>
>>It depends on your needs. If you can tolerate some complication
>>during the programming cycle in order to gain performance
>>at runtime, you might consider the "Compact Selector-Indexed
>>Dispatch Table". It is usually associated with static systems,
>>but it is easy for me to see how to make table management
>>incremental in order for it to work with systems like Smalltalk.
>
>I have read this paper and it wasn't immediately clear how to make
>it incremental without a big wait each time a selector is added to
>the system.
OOPs, I was wrong. I was thinking of another paper: "Taming Message
Passing" by Vitek & Horspool which uses selector coloring and
conflict tables. The papers you pointed out look more promising,
thanks.
--- james mccartney james@clyde.as.utexas.edu james@lcsaudio.com
If you have a PowerMac check out SuperCollider, a real time synth program:
ftp://mirror.apple.com//mirrors/Info-Mac.Archive/gst/snd/super-collider-demo.hqx
Date: 96 Dec 09 4:13:58 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: jecel@lsi.usp.br
Cc: squeak@create.ucsb.edu
In-Reply-To: <32A856DC.3A9E79D8@lsi.usp.br> (message from Jecel Assumpcao Jr
on Fri, 06 Dec 1996 15:24:44 -0200)
Subject: Re: inline caches
Jecel,
> In his dissertation, Urs Hoelzle speculates on various ways
> on which an efficient Self interpreter could be constructed.
> On page 32, he writes:
>
> Alternatively, the interpreter could just add inline
> caching to the straightforward interpreter by adding
> one pointer per send byte code to cache the method
> last invoked by that send; each method would also
> cache the last receiver type. Similar organizations
> have been used for Smalltalk interpreters. Since most
> bytecodes are sends, this approach would require
> roughly one word per byte code.
I read somewhere (I can't remember the reference offhand) that the majority
of methods in Smalltalk are polymorphic, yet the majority of message sends
are not. You therefore get much better type locality at send sites than you
do at method entry points.
For this reason I have always advocated (and implemented) "point of send"
inline caches, where the class of the receiver is kept at the send site
rather than in the method itself. For example, a "posic" could look
something like this (in pseudo-bytecodese):
push receiver & args
call <nArgs>
.oop lastClass # class of last receiver -- initially nil
.oop selector # set by compiler, never changes
.oop method # destination method -- initially nil
(If you use a dynamic translation scheme, to native or threaded code for
example, you would have the translated method's address instead of its oop as
the third element in the cache.)
Assuming an "ENTER(nArgs, method)" macro which enters the given method with
the given number of arguments (and which evaluates the second argument only
once), a "MCACHE_LOOKUP(class, selector)" macro which does the obvious thing,
and ignoring primitive response and #doesNotUnderstand, the "call" opcode
would look something like this:
oop cls;= classOf(stack[nArgs]); // class of receiver
if (cls == *ip) // compare with cache
{
/** hit **/
ip+= 2; // skip over cache elements
ENTER(nArgs, *ip++); // enter the method
/* notreached */
}
else
{
/** miss **/
oop method;
*ip++= cls; // save the actual class
method= MCACHE_LOOKUP(cls, *ip++); // lookup selector in method cache
ENTER(nArgs, *ip++= method); // save and enter method
/* notreached */
}
> I also looked at how many literals in the literal arrays
> are used as message selectors (table 1), and found that
> most are. It seems to me that we could create a shadow
> array for the literal array to store pointers used as
> pseudo inline caches without having too much space
> wasted.
This would potentially spread a single cache line over many send sites. Each
of these sites may well have the same selector, but there is no reason to
assume that the class of the receiver is related between any two of these
sites. For example, consider an implementation of #printOn: which is
implemented in terms of several other sends of #printOn:. Each send, in
isolation, has a very good changes of being monomorphic (many will actually
be to "constant" receivers) -- but there is a low probablity that all the
sends are to the same class of receiver. Spreading the cache over all the
sends of #printOn: forces them all to be polymorphic, with a very low type
locality.
This would reduce your hit rate considerably per send site. Add that to the
higher polymorphism that you would see by not using a point-of-send inline
cache (which is "spreading a single cache line" [in the method] over many
send sites [every send in the image which reaches that method]), and the
overall inline cache hit rate will probably be a lot lower than the
point-of-send scheme that I outlined above. (I have never measured this, but
I'd be very surprised if this statement is false. Of couse, whether any of
the affected methods are amongst the 10% in the image which have a
considerable impact on speed is another important consideration.)
> different call sites with the same selector *within*
> a method are more prone to have similar type profiles).
I am a little skeptical of this claim, in the absence of any dynamically
collected statistics.
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Dec 09 4:17:38 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: jecel@lsi.usp.br
Cc: plogan@teleport.com, squeak@create.ucsb.edu
In-Reply-To: <32A85098.7A4D2E97@lsi.usp.br> (message from Jecel Assumpcao Jr
on Fri, 06 Dec 1996 14:58:00 -0200)
Subject: Re: dynamic compilation
> I agree that one possibility would be to generate C code
> at runtime, call the compiler on that code and then load
> that code back into the system (via a DLL or something).
> The time and memory overhead of loading the C compiler
> would be very great, but the amount of code to be
> compiled would be so small that this might result in a
> usable system.
Assuming that this is a desirable thing to want to do, I think a more
sensible approach would be to steal a compiler back-end (from gcc, for
example) and have the Smalltalk runtime translate methods into RTL, instead
of C. But there are problems with using C compiler backends to generate code
for languages which might prefer non-C-like calling conventions.
Ian
Date: 96 Dec 09 4:32:33 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: james@clyde.as.utexas.edu
Cc: jecel@lsi.usp.br, squeak@create.ucsb.edu
In-Reply-To: <v01530501aece3f1bf184@[128.83.128.106]>
(james@clyde.as.utexas.edu)
Subject: Re: inline caches
> I've wondered whether polymorphic inline caches are really more space
> efficient than just flattening the method lookup hash table for a class
> so that it includes all its superclasses' selectors. The method hash would
> always hit without looking up the tree. This would be a space overhead
> equivalent to C++'s vtables. That's a lot, but don't inline caches use up
> quite a bit of space as well?
I tried this once, in PS2.3. The space explosion is *immense*. (I could
never make it work becuase the runtime couldn't keep up with the space needed
by the method dictionaries, and it kept dumping core on me.)
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Dec 09 7:21:28 am
From: Jecel Assumpcao Jr <jecel@lsi.usp.br>
To: Ian Piumarta <piumarta@prof.inria.fr>
Cc: squeak@create.ucsb.edu
Subject: Re: inline caches
> I read somewhere (I can't remember the reference offhand) that the majority
> of methods in Smalltalk are polymorphic, yet the majority of message sends
> are not. You therefore get much better type locality at send sites than you
> do at method entry points.
In one of the first SOAR papers, the following reference is given
for inline caches:
"An Upper Bound for Smalltalk-80 Execution on a Motorola 68000
CPU"
L. P. Deutsch, private communications, 1982
I know this doesn't help much, but I think that this is where your
information came from.
> ["point of send" inline cache details]
I've always thought that this was better than storing the last
class in the method prolog too.
> > I also looked at how many literals in the literal arrays
> > are used as message selectors (table 1), and found that
> > most are. It seems to me that we could create a shadow
> > array for the literal array to store pointers used as
> > pseudo inline caches without having too much space
> > wasted.
>
> This would potentially spread a single cache line over many send sites. Each
> of these sites may well have the same selector, but there is no reason to
> assume that the class of the receiver is related between any two of these
> sites. For example, consider an implementation of #printOn: which is
> implemented in terms of several other sends of #printOn:. Each send, in
> isolation, has a very good changes of being monomorphic (many will actually
> be to "constant" receivers) -- but there is a low probablity that all the
> sends are to the same class of receiver. Spreading the cache over all the
> sends of #printOn: forces them all to be polymorphic, with a very low type
> locality.
Good point, though my data shows this wouldn't be a problem for
at least 63% of the methods (which have at most one send per
literal). I will have to try to get some more statistics (not
this week, unfortunately), but my experience makes me feel that
#printOn: is the exception.
> This would reduce your hit rate considerably per send site. Add that to the
> higher polymorphism that you would see by not using a point-of-send inline
> cache (which is "spreading a single cache line" [in the method] over many
> send sites [every send in the image which reaches that method]), and the
> overall inline cache hit rate will probably be a lot lower than the
> point-of-send scheme that I outlined above. (I have never measured this, but
> I'd be very surprised if this statement is false. Of couse, whether any of
> the affected methods are amongst the 10% in the image which have a
> considerable impact on speed is another important consideration.)
I don't see how to get the dynamic information we need to find out
these things without generating an instrumented VM. Fortunately,
Squeak is the perfect system in which to do something like that.
> > different call sites with the same selector *within*
> > a method are more prone to have similar type profiles).
>
> I am a little skeptical of this claim, in the absence of any dynamically
> collected statistics.
I agree you should be skeptical. My experience with Smalltalk led me
to that conclusion, but it has often been wrong in the past.
-- Jecel
Date: 96 Dec 09 7:43:34 am
From: Ian Piumarta <piumarta@prof.inria.fr>
To: jecel@lsi.usp.br
Cc: squeak@create.ucsb.edu
In-Reply-To: <32AC068A.6200FDDA@lsi.usp.br> (message from Jecel Assumpcao Jr
on Mon, 09 Dec 1996 10:31:06 -0200)
Subject: Re: inline caches
> I will have to try to get some more statistics (not this week,
> unfortunately), but my experience makes me feel that #printOn: is the
> exception.
You may well be right about the intra-method use of selectors. I still think
that the inter-method use of selectors is highly polymorphic in important
places: the #retryCoercing: mechanism, for example, would lose badly using a
single-element inline cache with the previous receiver cached in the method
prologue.
> I don't see how to get the dynamic information we need to find out
> these things without generating an instrumented VM.
That's precisely what's required. This could be done either (1) by actually
implementing runtime translation in Squeak and then adding inline caches to
the code -- but then the question becomes academic since you'd be more
excited by actually trying out the various cache morphologies and
benchmarking them to find the best one, rather than instrumenting it to
collect data. In most Smalltalks you could also (2) instrument the image's
"interpreter" (the one used for single-stepping in the debugger) and then
emulate your way through a bunch of representative benchmarks. Squeak offers
another alternative which is (3) instrumenting the Smalltalk VM
implementation, and then running an image in Squeak using the instrumented
VM.
All we need is a volunteer with a little spare time on their hands...
;^)
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: Ian.Piumarta@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
Date: 96 Dec 10 4:21:18 am
From: Georg Gollmann <gollmann@edvz.tuwien.ac.at>
To: squeak@create.ucsb.edu
Subject: View framework changes
Hello,
once again I have messed with the view framework. Here's a short description:
Remove the instVar 'status' from StandardSystemController (no real need for
it). Add an instVar 'dirtyRect' to ControlManager to avoid displaying the
new top window twice when another window is closed. This is mostly useful
when view caching is off.
See ´viewScheduling.st´ at <http://ftp.tuwien.ac.at/~go/Squeak>.
Georg
----
Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum
phon:(++43-1) 58801 - 5848
mail:gollmann@edvz.tuwien.ac.at
http://ftp.tuwien.ac.at/~go/Gollmann.html
Date: 96 Dec 10 2:01:12 pm
From: Dan Ingalls <DanI@wdi.disney.com>
To: squeak@create.ucsb.edu
Subject: Upcoming Release, HyperSqueak, Dissemination
A couple of announcements on behalf of the Squeak team...
First, we should release 1.18 (or so I think it will be called), in a
couple of days. I'll put a summary of much of what it will contain at the
end of this message. In addition there will be a number of changes folded
in to enhance portability and Floating-point performance of the VM. These
are largely due to valuable contributions from all of you, along with a
fair amount of work by John Maloney, pulling it all together.
Second, beginning with 1.18, we will no longer distribute HyperSqueak as a
part of the Squeak image. If this is important to you, save your latest
image and work with the deltas, and feel free to communicate with us
regarding our work on and your interest in HyperSqueak. This will simplify
the process of explaining and releasing Squeak for us, and also makes it a
bit easier to focus on one of our goals which is to produce a lean and yet
flexible O-O kernel.
Third, I got a message expressing concern about a bug in 1.16 that was
explained and fixed in 1.17. If we had more resources, we would announce
and track every bug in every release we put out. However, given the
resources at our disposal, we operate with a leaner commitment which is:
to announce and fix most bugs we know about in the latest release, but not
to pay any attention to past releases. I tell you this by way of
apologizing for not being able to do more, and in the hopes that serious
Sqeakers will at least peruse the READMEs that go out with each release so
as to be aware of problems and fixes that are may already be known and
dealt with, as well as new features that are available.
Here's a summary of what's coming in 1.18 exclusive of John's work on the
VM and a few other last-minute goodies...
--------------------------------------------------------------------------------
------
"1.17 --> 1.17c..."
"Fixes an inconsistency between compiler sizing and code generation."
(FileStream readOnlyFileNamed: 'VitalFixFor1.17.st') fileIn.
"Make it so the Squeak Welcome window stays in color"
(FileStream readOnlyFileNamed: 'SqueakWindowInColor.doit') fileIn.
"Allows menus to scroll well even when form caching is disabled.
Also keeps scrolling going through the last item which didn't used
to work if you pulled the cursor far off-screen. Finally, fixes a
subscript error possible when scrolling SelectionMenus."
(FileStream readOnlyFileNamed: 'MenuScrolling-di.cs') fileIn.
"Fix a bug in filing out of HyperSqueak scripts"
(FileStream readOnlyFileNamed: 'Script fileOut fix.cs') fileIn.
"Implements the message reversed uniformly in String and other collections.
Then updates a couple of methods to use it instead of supplanted msg,
backwards."
(FileStream readOnlyFileNamed: 'StringCleanups-di.cs') fileIn.
"Continues the support of font sets by making a subclass for them.
Subclasses of this class will not clog the changes file."
(FileStream readOnlyFileNamed: 'FontSets-di.cs') fileIn.
"Makes it possible to open GIF files from the fileList and see them in a
window.
Fixes a FormView scaling problem. Also adjusts window frame defaults."
(FileStream readOnlyFileNamed: 'ImportingImages-di.cs') fileIn.
"Makes it possible to open .form files as well as GIFs from the fileList.
Makes a bit of the Form Editor accessible in FormViews."
(FileStream readOnlyFileNamed: 'ImportingImages2-di.cs') fileIn.
"Fixes a few methods caught by formatter changes."
(FileStream readOnlyFileNamed: 'WeirdMethodFixes-di.cs') fileIn.
"Fixes a number of problems in the formatter, mainly to do with to:do: blocks."
(FileStream readOnlyFileNamed: 'FormatterFixes-di.cs') fileIn.
"Makes it possible to inform the decompiler of temp names, resulting
in fairly readable decompiled source. Browse with shift key to test."
(FileStream readOnlyFileNamed: 'MagicSources1-di.cs') fileIn.
"Two more files that makes it seriously possible to convert the system
to browse without sources but with temp names and decompilation."
(FileStream readOnlyFileNamed: 'MagicSources2-di.cs') fileIn.
(FileStream readOnlyFileNamed: 'MagicSources3-di.cs') fileIn.
"Fixes the infamous method cache reprobe inconsistency in the VM."
(FileStream readOnlyFileNamed: 'InterpreterReprobeFix.st') fileIn.
"Enables the compiler to recognize undefined temporary variables.
Will alert the user if in interactive mode (but not, eg, in fileIns)."
(FileStream readOnlyFileNamed: 'CheckUndefTemps-di.cs') fileIn.
"Enables the compiler to recognize unused temporary variables.
Will alert the user if in interactive mode (but not, eg, in fileIns)."
(FileStream readOnlyFileNamed: 'CheckUnusedTemps-di.cs') fileIn.
"Removes an ineffective attempt at correcting missing periods and
agglutinated keywords. The logic was OK, but couldnt restart the compiler."
(FileStream readOnlyFileNamed: 'RemoveBadCorrection-di.cs') fileIn.
"Makes the decompiler work better on do-loops."
(FileStream readOnlyFileNamed: 'DecompileDos-di.cs') fileIn.
"A major change to the treatment of temporary variables. Recognizes
the difference between declared temps and block args in compiler and
decompiler as well. Not true support for block structure, but will no
longer allow a block arg to be used if declared in an outer scope."
(FileStream readOnlyFileNamed: 'BlockStructure-di.cs') fileIn.
"Fixes a failure of the browser to find all stores into a given inst var."
(FileStream readOnlyFileNamed: 'instVarDefsFix-di.cs') fileIn.
"Fixes a failure of forward delete when at paragraph end."
(FileStream readOnlyFileNamed: 'ForwardDeleteFix.st') fileIn.
"Many methods adjusted to conform to new block structure rules.
With few exceptions this simply amounted to removing a block
temp from the list of temps declared for the method as a whole."
(FileStream readOnlyFileNamed: 'ManyTempDeclFixes-di.cs') fileIn.
"A number of tweaks required to make sourceless browsing really work.
Also a fix for ProjectView when windows lie outside the screen, and
a fix to the simulator to run the text primitive without failing."
(FileStream readOnlyFileNamed: 'SundryTweaks-di.cs') fileIn.
"1.17c --> 1.17e..."
"Works around the long-standing problem that a class-rename change was
reflected in a change-set fileout by a do-it that would fail in any image
that did not have a class of the old name present in it. This fix changes
things so that the class-rename request is made by a message to Smalltalk,
which can be a little more clever about handling the class-not-in-existence
case."
(FileStream readOnlyFileNamed: 'RobustClassRename.cs') fileIn.
"Allows the user to specify a desktop color by choosing from a palette of
colors. Derived from an idea and code supplied by Georg Gollmann in
November 1996."
(FileStream readOnlyFileNamed: 'ColoredDesktop.cs') fileIn.
"Derived from several goodies made available by Steven Travis Pope in
November 1996, with some minor modifications in 12/96 by sw, this change
set enhances the browsers by:
Adding a Protocol Browser
Adding a Recent Classes... feature
Restoring the in-browser Hierarchy feature while retaining di's
separate Hierarchy Browser."
(FileStream readOnlyFileNamed: 'STPBrowserEnhancements.cs') fileIn.
"Contains various enhancements relating to Change Sets and Change Sorters,
including:
* When you open a new Change Sorter, two different change sets are
initially shown -- the current one and a recently-created one.
* Adds a Clear feature to the Change Sorter.
* A Change Set can have a Preamble, which you can edit, and which goes
out onto the fileout file before the actual code changes are written to it.
Similarly, it can have a PostScript, which goes out onto the fileout file
after everything else."
(FileStream readOnlyFileNamed: 'ChangesChanges.cs') fileIn.
"Combined generic (non-HyperSqueak-class) changes by sw between 1.16 and
12/4/96, EXCEPT for code separately shipped as documented goodies, and
EXCEPT for private code not to be put into the public image."
(FileStream readOnlyFileNamed: 'SWMiscGeneric.cs') fileIn.
"Holds all changes to all classes in HyperSqueak categories made between
the release of Squeak 1.16 and the brink of 1.18"
(FileStream readOnlyFileNamed: 'HSDelta4Dec.cs') fileIn.
"Fixes atWrap: for String when index is not an integer ('abc' atWrap: 4.2)."
(FileStream readOnlyFileNamed: 'String-atWrap.st') fileIn.
"This ChangeSet removes the old #costumes inst var from Obj, adds new inst
var #currentWorkingsCostume to Obj, and adds new inst var
#currentContentsCostume to Folder, in anticipation of future
transformations discussed on 12/5/96 by tck, jm, and sw"
(FileStream readOnlyFileNamed: 'ObjInstVarChng.cs') fileIn.
"Fixes several bugs:
Subscript out of bounds when typing new lines into cetered text,
Cmd-K style choice did not copy its textStyle,
Parser remove-temps menu caption had tabs
Menu captions had too little line leading.
It also adds two features:
Adds symbolic messages centered, leftFlush, rightFlush, justified
to TextStyles,
Adds Cmd-Menu control over whether StandardSystemViews save full
color or not.
Finally, it resets TextStyle default to leftFlush.
NOTE that any windows which used Cmd-K should re-execute
Cmd-K to get a copy of the global default TextStyle."
(FileStream readOnlyFileNamed: 'FixesTo1.17d-di.cs') fileIn.
"Removes two methods in String (prefixEqual: and hasPrefix:,
which did the same thing), and replaces them with an equivalent
method named beginsWith:, to establish symmetry with the other
pre-existing method, endsWith:."
(FileStream readOnlyFileNamed: 'BeginsWith-di.cs') fileIn.
"Fixes two bugs:
If you got a syntax error when recompiling a class (as when adding
an instVar that was used somewhere as a temp), and tried
to proceed after correcting it, you kept getting the same
error.
If you added an instance variable as the last one, classes did not
get recompiled, and thus did not catch the eror alluded to
above.
It also adds a new feature:
Syntax errors now proceed automatically whenever compilation succeeds."
(FileStream readOnlyFileNamed: 'SyntaxErrorFixes-di.cs') fileIn.
"HyperSqueak: converts one further method that had called #prefixEqual:
(which just vanished) over to calling #beginsWith:, and also uses the
opportunity to improve the HyperSqueak method affected, whose intent is to
remove user-defined pictures from the picture library, by now only removing
such pictures if they're not currently associated with any extant HS
object, and by now also reporting the results of the sweep in the
Transcript"
(FileStream readOnlyFileNamed: 'PicRemoveFix.cs') fileIn.
"Handy menu command for demos when you want to show the bytecodes of a method."
(FileStream readOnlyFileNamed: 'ShowBytecodesCommand.cs') fileIn.
"Two unrelated bug fixes."
(FileStream readOnlyFileNamed: 'ListViewFixes.cs') fileIn.
"Fixes latent bug that was masked by an oversight in the file read primitive."
(FileStream readOnlyFileNamed: 'FileStreamFix.cs') fileIn.
"Faster send/return. Also fixes minor bug in method cache."
(FileStream readOnlyFileNamed: 'FasterSends.cs') fileIn.
Date: 96 Dec 10 4:04:29 pm
From: stp (Stephen Travis Pope)
To: Ian Piumarta <piumarta@prof.inria.fr>, ames@clyde.as.utexas.edu
Cc: jecel@lsi.usp.br, squeak@create.ucsb.edu
In-Reply-To: Ian Piumarta <piumarta@prof.inria.fr>'s letter of: 96 Dec 09
Subject: Re: inline caches
> I've wondered whether polymorphic inline caches are really more space
> efficient than just flattening the method lookup hash table for a class
> so that it includes all its superclasses' selectors.
Am I missing something, or are you folks overlooking the fact that
polymorphism is often found among classes that are not related by inheritance
(i.e., they share a specification without sharing the implementation)? I use
this quite heavily in several of my applications.
stp
_Stephen Travis Pope--Center for Research in Electronic Art Technology
_(CREATE), Dept. of Music, U. C. Santa Barbara
_ Editor--Computer Music Journal, MIT Press
_stp@create.ucsb.edu http://www.create.ucsb.edu/~stp/ http://www-mitpress.mit.edu/CMJ/
Date: 96 Dec 10 4:36:47 pm
From: Dan Ingalls <DanI@wdi.disney.com>
To: "David N. Smith" <dnsmith@watson.ibm.com>
Cc: squeak@create.ucsb.edu
In-Reply-To: <v03007801aed397a9040f@[129.34.225.178]>
Subject: Re: Smalltalk FAQ and Squeak
[Squeakers -
This is a somewhat long answer, on behalf of the Squeak team, to a query
from David Smith regarding the future of Squeak. It became clear that
others might be interested, hence the cc]
>Dan:
>
>I'm working on a major revision of my Smalltalk FAQ, hopefully for release
>in January 97 on the web. It has become clear that I cannot attempt to
>cover all implementations, partly because I don't have them all, and partly
>because of time. I've decided to concentrate on two sets of implementations:
>
>* Industrial strength: VW, VSE, and IBM.
>
>* Great freebies: Smalltalk Express, Squeak.
>
>If/when SW and VSE combine in to something, then I'll cover that instead,
>but I'm not holding my breath.
>
>That leaves Squeak. Of the bunch, it is the only complete implementation.
>It is the only one a student can study and see how a Smalltalk system
>works. It is fun to use, runs on a lot of platforms, and may well become a
>standard learning tool.
>
>My question is: Will Squeak be around for a while?
Yes, if I have anything to say about it.
>It's been said that your project is going somewhere with Squeak and
>HyperSqueak and that 'for a while' Squeak would still look like Smalltalk.
I have always been on the practical side of what our project does. I see a
great synergy in Squeak remaining essentially a Smalltalk, and a great loss
in synergy when it should depart significantly.
>Is it possible that it will evolve into something non-Smalltalk like? Is it
>a mistake to include it in my FAQ, considering that I hope for hardcopy
>publication in 1997 and a 3 year shelf life?
Yes, it is possible that it will evolve into something that you would not
consider a Smalltalk. I think we would be entirely conscious of approching
that threshold, though. We would certainly work to inform people in
advance of this happening, and find some ad-hoc committee to preside over
Squeak's future existence should we go a another way. It is certainly much
easier to hand off than any other Smalltalk I've worked on, and I think
that as it finds its way farther into academia a bunch of people will be
interested in keeping it going.
>I'm not looking for a prediction, but just your sense of whether or not
>Squeak as a Smalltalk system is apt to stay available.
Well, now you have my sense. There is more to it, also. We are getting
fully as much out of this [the sharing] as we are putting into it.
Consider the ports that are already out there, and a number of goodies and
ports of other valuable susbsystems. It's clear that we would lose a lot
of that with any radical departure.
The only immediate threat that I feel right now to continuity of Squeak's
underlying semantics is our desire to be a bit more instance-oriented than
class-oriented, as in Self or GlyphicScript. This makes it easier to
introduce people through concrete construction of new objects and
incremental specification of their behavior. But I think this is better
provided as a prototype-oriented construction framework built on top of the
classic ST model than as the more free-form semantics. It doesn't give you
quite as much generality, but it retains a simple approach to organization
that has stood the test of time. So my thrust in this case would be to add
value on top of Squeak-as-ST rather than to divert Squeak.
There are numerous threats to the current Squeak graphics model and UI
architecture. These I view as positive; It's an old architecture and
fairly heavily barnacled. But I don't think folks would be that upset
about replacing all of the current viewing structure, as long as the
replacement was simpler, easier to use, more powerful, etc. Again, though,
even the Squeak team will want some compatibility path for a while. I'm
hoping that we can move the system to pluggable views in the next month,
and then toward an architecture simlar to the one John did for Self, with
proper management of display ports and damage rectangle updates.
[We're hoping that HyperSqueak can be the vehicle for bringing much of this
together, but in the short term we're taking that work offline, as it will
be undocumented, inconsistent, and confusing during the rapid change phase]
I think the thrust of the Squeak group will remain with native graphics
(toolbox in smalltalk with minimal bios-like [bitblt +] support from the
host), but I'm hoping that, as a community, we can pull this off with a
layering like
| ---
bitblt/bios portable implem
| --- Mac
host implem
| ---
Windows host implem
application --- platform-indep layer <
| --- X
windows host implem
| --- tk implem
so that we can each have our cake and eat it too. We can use help here, if
anyone has a lot of experience and clarity about how to make this work well.
>PS: The name Squeak makes much more sense at Disney than at Apple. Is that
>just an odd coincidence? :-)
We neededsome name at Apple for what we were doing, and it was felt that
"another Smalltalk" would not have been politically correct. Squeak was
cute, and it is, after all, an instance of small talk.
PS: ...but that doesn't answer your question. ;>)
- Dan
stp@create.ucsb.edu]
Created: 1996.11.08; LastEditDate: 1996.11.11