Embedded Squeak 1.0 released for Squeak 2.2

Paul Fernhout pdfernhout at kurtz-fernhout.com
Wed Dec 23 15:57:01 UTC 1998


Sven Dowideit wrote:
> do I read this correctly? 
> you _are_ working on a Newton port?

As I wrote to the list two years ago (on 12/21/96):
) ... for those of us who already use Smalltalk for other projects,
) Squeak on a Newton is a way to stretch our imaginations 
) in new directions as to what Smalltalk can be about. 

Having started it, the Newton port will be an albatross around my neck
until such time as I (or someone else) can say version 1.0 is done... 

A full port under Newton OS is just at the edge of technical feasibility
for the MP2100 or expanded eMate. The single biggest issue with the
Newton port is lack of good C++ debugging support in Apple's tools.
There are several others, next in importance being that users will be
*very* annoyed if a C/C++ program crash kills their Newton, which
supposedly can happen (by crashing in such a way as to overwrite
critical memory somewhere which isn't backed up), although I've never
seen this personally. And, as an earlier thread shows, it is quite
possible to crash the VM from within Smalltalk. Now that you've been
properly warned, liabilities disclaimed, received suggestions to back up
and not do this on a mission critical Newt, etc., we can proceed.

Embedded Squeak (Squeakette) is so simple to deploy, almost no debugging
(relatively speaking) will be required to get the minimal implementation
to work on any platform with a C compiler and some form of character I/O
(serial, console, socket, etc.). So, I have hopes it might work right
the first or second time on the Newton. Since Squeakette eliminates the
need for loading and saving files, or doing keyboard I/O, bitmap
display, and mouse tracking, those issues can be ignored at the start,
and dealt with as desired over time.
 
For example I just got Squeakette to work under VxWorks on a client's
prototype hardware (MIPS type chip). It took two days. Most of the time
was spent diagnosing the "32 bit clean" issue Georg posted about
previously. Besides filing in Georg Gollman's patch and regenerating
'interp.c', and aside from creating a makefile (defining 'EMBEDDED' and
'mips'), renaming main() to mainInterpret(), and calling mainInterpret()
from standard VxWorks file 'userConfig.c', all I really had to do was
change the serial input primitive to remove the keyboard hit test
(Windows call) and switch _getch() with getchar(). Also, I had to add a
line right after getchar() to convert ascii 10 to ascii 13 for a proper
line end (otherwise Squeak just echoed input and never processed it,
since the main loop waits for a Character cr (not a Character lf) before
processing). While it all could be improved (and of course should not be
used in life support equipment, nuclear power plants, flight control
systems, etc.), it works.

Of course, Squeakette only chats over the console serial port. However,
the Squeak VM serial I/O primitives can be enhanced to send and receive
messages via named pipes or sockets (keeping the VM separate from the
rest of the system), with each named pipe or socket being assigned a
separate serial port number, allowing one to do unlimited I/O from those
two serial primitives.

[By the way, I noticed if you open the current 'embedded.image' on a PC
without COM2, it warns about a primitive failure -- just change the
default serial port in EmbeddedSystem from 2 to 1, save the image and
quit, and you're fine on reloading the image.]

> what level HW are you going for??

MP2100 or Expanded eMate. I'd like to run under MP2000 or MP130 if we
could get the image size (Compiler + core base classes) down to 100K or
so, and cut warpblit etc. (sorry Dan! :-) out of the VM to bring that
down to 100K or so too.  A 200K C binary + NewtonScript shell might be
able to run on the MP130 or MP2000.

> I have a dream to pull the ROMs from a 120 (or better) and give the best HW
> form for me a nice life.
 
Sounds great, but Apple still hasn't released enough specs to use the
underlying hardware by making your own ROMS. I'd love to do the same too
though. There are many power management and device driver issues that
would need to be overcome though.
 
> and Squeak seems like the 'place' (grin) for me.

And the rest of us, too!

> I currently have a 110, and am curious about what you are up to, 

You might say my current approach is inspired by Forth.

I have a NewtonScript shell I wrote a year or so ago, which currently
hosts a Forth (written in NewtonScript, but based on eForth by Bill
Muench, and developed in collaboration with him). The shell is a window
that floats above the notepad (or any other text edit). It has a drop
down menu with among other things "do it". You select some Forth written
in the Notepad, and then you choose "do it" and the results are added
right after after the Forth code in the same notepad entry. (That this
was doable at all, let alone easily, is a tribute to the NewtonOS). The
Forth "image" is persistent as long as the shell window is up. I would
like to do the same thing with Squeakette.

> and if you
> would like a slave... (I have a bit of time, don't know much 
> Smalltalk yet, but I've used a few different platforms, 
> and program for a living)

I'd very much like any help I can get on improving Squeakette (as long
as such improvements are put under the Squeak license).

However, although your offer is tempting, I don't believe in slavery --
it's not practical in the long term due to low morale, low productivity,
sabotage, rebellion, etc. (let alone moral by today's standards). 

But, if you wanted to be a great help as a collaborator :-), you could
modify the Squeak VM translator (Smalltalk->C) to generate the Squeak VM
as a C++ class. Shouldn't take that long, and it could be a great
learning experience. My hand-translated C++ 1.21 VM is now quite out of
date. Making the VM a C++ class needs to be done because C/C++ compiler
for the Newton does not support globals (don't ask me why, since other
ARM C compilers do allow them). The idea is that you make a VM class
instance and then all its calls pass itself around. I already have
NewtonScript support code to make a VM object and call its interpret
routine. This work would be useful whether or not a Newton port uses it. 

Alternatively, if you could investigate creating an expression in
Smalltalk which would close all windows, and then remove all GUI
classes, (and also map the debugger and notifier to
EmbeddedSystem>>report calls), I'd be much obliged. Doing this well
would require a thorough investigation of Squeak processes, and also
mapping out how the base system calls the GUI. I'm hoping this would let
us reduce the image size to 100 - 200K.
 
Or instead, figuring out what code can be dropped out of the interpreter
for a headless Squeak (bitblit, sound, other optional primitives), would
be a great help in reducing the footprint. What primitives are essential
for basic embedded operations (i.e. compilation and text processing)?

Or, investigating why the Apple C++ tools crash (after taking forever)
when trying to compile a definition of the image as a memory array would
help. I had a similar problem with VC++, but found a compiler switch to
fix it ( /Zm500 ). Is there a compiler option I could use with Apple's
tools, or could we get someone like Tim Rowledge to compile the image
for us on another ARM machine and give us a useable image.o file?

Or, if I had a version of the Squeakette Squeak VM and image which
accepted a string, processed it, and returned a string as a single
function call like:
int sqPrintIt(char* doItString, char* resultString, int resultLength);
I could then link this Newton shell to it. The current Squeakette system
does process characters and return characters, but there are some issues
to be resolved in terms of who calls whom when, (how exactly the VM
cycles and interoperates with the caller). 

I am currently toying with such issues as a Windows ActiveX control to
be used with Delphi (similar to Python for Delphi
http://www.robanal.demon.co.uk/demos/pyvb/index.htm ), but similar
issues need to be resolved for the Newton. However, this may be complex,
as Blake McBride pointed out earlier, and so probably isn't the best
issue for you to start with (unless you're comfortable with VC++ and
like the idea of doing an ActiveX control to get started with Squeak,
with the though that the ActiveX control would work much like a Newton
version of Squeakette).

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the GPL Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com





More information about the Squeak-dev mailing list