SqueakOS

[Markus Kohler]

Jerry Bell wrote:
>
> I'm new to the list, but I've found some references to 'bare-metal' Squeak
> implementations. Is anyone working on this?
>
> What would be the ideal kind of kernel to run Squeak on top of? I know
> portability would be on the top of the list. How about single vs.
> multithreaded? Maybe even something completely different to take advantage
> of the unique needs of a smalltalk environment?
>
> I assume that a goal would be to eventually make Squeak classes that could
> generate the low-level kernel code for a given platform, much like the
> interpreter generator. Then, to port to another platform you would simply
> define the characteristics of that specific platform. All from within
> Squeak. That would be.... nice.
>
> I don't have much experience with Smalltalk, and even less with OS design.
> But it seems that one way to approach this would be to build something
> quickly using simple, existing tools. Then, when there is a working system
> we could factor parts of the original low-level code out and replace them
> with code generated by Squeak. At that point, we could make refinements in
> speed, portability, etc. from within Squeak itself.
>
> Specifically, I've started looking at FreeDOS's kernel, dos-c, as a
> possible starting point. There is already a DOS port of Squeak out there,
> and it seems as if it would not be too terribly complicated to take dos-c
> and the DOS port of Squeak and kinda mash them together to make a booting
> SqueakOS. Plus, the dos-c kernel is supposed to be pretty portable, and is
> written mostly in C so it shouldn't be not TOO hard to work with. It
> should also be simpler than a more advanced kernel. And, it's GPL'd.

I would rather try a Linux port to ggi (http://synergy.foo.net/~ggi/).
Some (older) stripped down Linux kernels seem to run in 1MB. If you
would
throw out the file system and replace it by something simpler, I guess
you would gain again some memory.

>
> I've just started looking at dos-c, I'm reading the author's book now.
> Unfortunately, it doesn't look like the current version of dos-c will
> handle the DPMI stuff that the DOS port of Squeak needs, but maybe that
> would be easy to fix for someone who knows what they are doing?

I guess it's not that easy because Squeak assumes a 32bit memory model.


Markus

--
Markus Kohler mailto:***@hp.com

[Tim Rowledge]

On Sat 14 Nov, Jerry Bell wrote:
> I'm new to the list, but I've found some references to 'bare-metal' Squeak
> implementations. Is anyone working on this?
Yup. We've been doing stuff along those lines for a while now. We have
custom hardware to run it on and can also run the same images on 'normal'
machines, though without the sort of full-control you can get with your own
h/w.
>
> What would be the ideal kind of kernel to run Squeak on top of? I know
> portability would be on the top of the list. How about single vs.
> multithreaded? Maybe even something completely different to take advantage
> of the unique needs of a smalltalk environment?
We sort of started from the ARM/Digital 'Angel' + a sort-of port of
microC/OS (I always think of it as 'mucus' because it snot an OS) and then
waltzed off into the sunset.

>
> I assume that a goal would be to eventually make Squeak classes that could
> generate the low-level kernel code for a given platform, much like the
> interpreter generator. Then, to port to another platform you would simply
> define the characteristics of that specific platform. All from within
> Squeak. That would be.... nice.
It was, it does and it is. Mix in the direct-compile for primitives that
Hans-Martin has also spent some time on along with something like Andreas'
pluggable prims and yo uget quite a useful improvement on DLLs.

If there is serious interest in acutally using this sort of thing (not to
mention handling the work of writing code-gen backends for non-ARM cpus) we
might be able to release the code translator. Be warned - it requires quite
a bit of syntactically rejigging the VM code, like getting rid of all the
#cCode: stuff. Personally I think that makes it worth doing by itself :-)

tim

--
Useful random insult:- Couldn't hit water if he fell out of a boat.
Tim Rowledge: ***@interval.com (w) [phone] (w)
***@sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

[Jerry Bell]

I'm new to the list, but I've found some references to 'bare-metal' Squeak
implementations. Is anyone working on this?

What would be the ideal kind of kernel to run Squeak on top of? I know
portability would be on the top of the list. How about single vs.
multithreaded? Maybe even something completely different to take advantage
of the unique needs of a smalltalk environment?

I assume that a goal would be to eventually make Squeak classes that could
generate the low-level kernel code for a given platform, much like the
interpreter generator. Then, to port to another platform you would simply
define the characteristics of that specific platform. All from within
Squeak. That would be.... nice.

I don't have much experience with Smalltalk, and even less with OS design.
But it seems that one way to approach this would be to build something
quickly using simple, existing tools. Then, when there is a working system
we could factor parts of the original low-level code out and replace them
with code generated by Squeak. At that point, we could make refinements in
speed, portability, etc. from within Squeak itself.

Specifically, I've started looking at FreeDOS's kernel, dos-c, as a
possible starting point. There is already a DOS port of Squeak out there,
and it seems as if it would not be too terribly complicated to take dos-c
and the DOS port of Squeak and kinda mash them together to make a booting
SqueakOS. Plus, the dos-c kernel is supposed to be pretty portable, and is
written mostly in C so it shouldn't be not TOO hard to work with. It
should also be simpler than a more advanced kernel. And, it's GPL'd.

I've just started looking at dos-c, I'm reading the author's book now.
Unfortunately, it doesn't look like the current version of dos-c will
handle the DPMI stuff that the DOS port of Squeak needs, but maybe that
would be easy to fix for someone who knows what they are doing?

Any suggestions?

Jerry Bell
***@fareselaw.com

Links:

http://www.iop.com/~patv/ - this is the dos-c site.
http://www.freedos.org/ - freeDOS, freely available DOS clone. Dos-c is
the kernel.

Book:
FreeDOS Kernel / Pat Villani , it's available at Amazon. I'm reading it
now and starting to look at the source.

[Paul Fernhout]

Jerry Bell wrote:
> I've found some references to 'bare-metal' Squeak
> implementations. Is anyone working on this?

Squeakers -

There was recently a discussion on comp.lang.forth on a bootable Forth
demo ("BootFORTH demo") recently released for FreeBSD. There has been
interest in the past for doing this for Squeak, although still no
working demo I know of (other than Squeak for DOS, which might in theory
boot from a floppy (size?), but still requires a non-free OS).

I would imagine the big issue isn't getting something to boot -- it is
having a knowledge base for interacting with the variety of graphics
cards, ethernet cards, modems, SCSI adapters, HD drives, etc.

Here are two links from the Forth discussion:

http://www.freebsd.org/~picobsd/
This page contains information on developing FreeBSD to work in various
small and unusual places, such as single floppy, vnode (vn(4))
partitions or embedded controllers. Includes image for single floppy
bootable Forth version.

http://www.moore160.freeserve.co.uk/dmjx.htm
David Moore's Joshua 32 bit x86 RT/Operating System

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

[johnm at wdi.disney.com ()]

Jerry Bell <***@fareselaw.com> wrote:
> What would be the ideal kind of kernel to run Squeak on top of? I know
> portability would be on the top of the list. How about single vs.
> multithreaded? Maybe even something completely different to take advantage
> of the unique needs of a smalltalk environment?

Squeak doesn't really need an OS, just device drivers. The minimum it
needs are a display driver and some combination of pen/mouse/keyboard
input drivers. It doesn't really even need a file system, although it's nice
to have. After that, it just depends on what you need: sound output, sound
input, networking (TCP/IP), etc.

Curtis Wickman, a summer intern, ported Squeak to a bare Mitsubishi
M32-R/D prototyping board (no OS) in about six weeks, including writing
all the device drivers. It took him a few more weeks to add a simple Flash RAM
file system and a sound output driver. The entire VM, including the drivers, was
under 250 KBytes.

So my approach to building a bare-machine Squeak would be to find
an open-source OS kernel and just adapt its device drivers. Squeak is really
its own OS, after all.

-- John

P.S. I know about the Interval and Mitsubishi bare-chip Squeak's. Are there
any other bare-chip VM's out there? (The DEC Itsy and Zaurus ports are neat,
but they run on top of a host OS.)

[Ryan Davis]

>Curtis Wickman, a summer intern, ported Squeak to a bare Mitsubishi
>M32-R/D prototyping board (no OS) in about six weeks, including writing
>all the device drivers. It took him a few more weeks to add a simple Flash RAM
>file system and a sound output driver. The entire VM, including the
>drivers, was
>under 250 KBytes.

How much do one of these toys cost???

Ryan Davis -=- Zen Spider Software
-=- mailto:***@ZenSpider.com -=- http://www.ZenSpider.com/ -=-
I know that you believe you understand what you think I said but,
I'm not sure you realize that what you heard is not what I meant.

[Randal L. Schwartz]

>>>>> "Andrew" == Andrew C Greenberg <***@gate.net> writes:

Andrew> Indeed, the iMac boots in a funny mode when you hold some
Andrew> magic keys down, into a Forth-like interpreter that seems to
Andrew> be closely related to device configuration. I recall seeing
Andrew> some press describing this awhile back, and some indication
Andrew> that more Apple computers will be using that thingie, whatever
Andrew> its called. OpenROM or OpenBoot sounds familiar.

Yes, the MkLinux people are familiar with the difference between
OpenBoot G3 Macs and those that aren't. (Almost?) all Macs coming off
the line right now are OpenBoot... and boots into a "forth-like" mode
(my Forth buddies tell me it is a real total Forth). My Wall-street
G3 Powerbook certainly is. (MkLinux people know it because MkLinux
works ONLY with OpenBoot Macs.)

--
Name: Randal L. Schwartz / Stonehenge Consulting Services [phone]
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <***@stonehenge.com> Snail: (Call) PGP-Key: (finger ***@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

[Fred Bacon]

"Randal L. Schwartz" wrote:
>
> Yes, the MkLinux people are familiar with the difference between
> OpenBoot G3 Macs and those that aren't. (Almost?) all Macs coming off
> the line right now are OpenBoot... and boots into a "forth-like" mode
> (my Forth buddies tell me it is a real total Forth). My Wall-street
> G3 Powerbook certainly is. (MkLinux people know it because MkLinux
> works ONLY with OpenBoot Macs.)
>

No, but close. :-) Linuxppc only boots on OpenFirmware based machines.
MkLinux will boot on machines which don't possess OF. (Older, NuBus
based powermacs.)

--
Fred Bacon

=========================================================================
Aerodyne Research, Inc. Phone: [phone] ext.
273
45 Manning Rd. FAX: [phone]
Billerica, MA 01821-3976 http://www.aerodyne.com
=========================================================================
People who want to share their religious views with you almost never
want
you to share yours with them. -- Dave Barry

[Andrew C. Greenberg]

> [Dredging into my memory, and anecdotal from a friend of mine...]
>
> I think Sun uses (or at least used to) something like this.
> It is based on Forth and is called OpenROM or something like that.
> I believe that all the adapters had enough of a driver stored onboard
> to support booting. It was supposed to be able to run on any of the
> platforms they supported. I just did a quick search and found
> references to OpenROM and OpenBoot. I believe that the guy
> that wrote this is a pretty well know Forth personage.
>
> Now the buzzword is I2O. Some believe this to be a plot by Intel
> to sell more 960's since most (all) I20 adapters have a 960 onboard.
> There is a lot of controversy over I2O in the Open Source camp.

Indeed, the iMac boots in a funny mode when you hold some magic keys down,
into a Forth-like interpreter that seems to be closely related to device
configuration. I recall seeing some press describing this awhile back, and
some indication that more Apple computers will be using that thingie,
whatever its called. OpenROM or OpenBoot sounds familiar.

[Sebastian Raul Wain]

I was thinking to port the linux (ix86) version of squeak to svgalib to
reduce
the amount of memory needed.
It seems interesting if you can put the linux & squeak in one booteable
floppy (or two!!!).
Sounds more challenging than the qnx challenge.

Sebastian Wain

[Dwight Hughes]

Also be sure to take a close look at the Flux OSKit version 0.96 just
released:

http://www.cs.utah.edu/projects/flux/oskit/

You can create very small "kernels" with just the resources required and
wrapper code from other unixy OSs.

-- Dwight

Sebastian Raul Wain wrote:
>
> I was thinking to port the linux (ix86) version of squeak to svgalib to
> reduce
> the amount of memory needed.
> It seems interesting if you can put the linux & squeak in one booteable
> floppy (or two!!!).
> Sounds more challenging than the qnx challenge.
>
> Sebastian Wain

[Andrew C. Greenberg]

A follow-up on my previous posting about Apple's Open Firmware. A website
dedicated to the same begins at:

http://azrael.uoregon.edu/imac/

[Sven Dowideit]

i was thinking that it would be better to go for GGI, and a good excuse for
someone to learn GGI too.


Cheers

Sven Dowideit
http://www.ozemail.com.au/~svenud

> -----Original Message-----
> From: ***@relay1.impsat1.com [mailto:***@relay1.impsat1.com]On
> Behalf Of Sebastian Raul Wain
> Sent: Monday, December 28, 1998 9:50 AM
> To: ***@cs.uiuc.edu
> Subject: SqueakOS
>
>
> I was thinking to port the linux (ix86) version of squeak to svgalib to
> reduce
> the amount of memory needed.
> It seems interesting if you can put the linux & squeak in one booteable
> floppy (or two!!!).
> Sounds more challenging than the qnx challenge.
>
> Sebastian Wain
>
>

[Marcus Denker]

On Mon, Dec 28, 1998 at 06:11:18PM +1100, Sven Dowideit wrote:
> i was thinking that it would be better to go for GGI, and a good excuse for
> someone to learn GGI too.
>
Yes. GGI is the way to go.

>From the FAQ:

|LibGGI is an attempt to unify all those graphical output systems that exist
|on Unix (and we even want to port to other systems as well).
|
|Linux alone has a pretty big set of graphics output subsystems:
|
|X, SVGAlib, /dev/fb (native or kgicon), LibAA, Glide, XF86-DGA, etc. ...
|
|LibGGI is an attempt to unify all of them. It is a very fast, simple (ever
|tried to make a small graphics app directly in Xlib ?) and lightweight
|interface layer, that allows you to run the _very_same_binary_ on all the
|above mentioned targets (as we call them). LibGGI will detect (or you can
|select, of course) the environment you are running in, and redirect its
|output as required. Forget about limiting yourself to just one graphics
|subsystem and just use LibGGI.
|
| ftp://ftp.ggi-project.org/pub/ggi/ggi/2_0_beta_1
| http://www.ggi-project.org

--
Marcus Denker ***@ira.uka.de ***@home:[phone] @work:[phone]

[Sebastian Raul Wain]

Marcus Denker wrote:

> On Mon, Dec 28, 1998 at 06:11:18PM +1100, Sven Dowideit wrote:
> > i was thinking that it would be better to go for GGI, and a good excuse for
> > someone to learn GGI too.
> >
> Yes. GGI is the way to go.

I am working in a port of Squeak to ggi.


swain

[Andrew C. Greenberg]

Finally (this is because I have now made three postings about a technology
I know nothing about), I note that the Open Firmware is subject to a IEEE
standard: IEEE Standard 1275-1994.

[Pennell's]

Paul Fernhout wrote:

>http://www.freebsd.org/~picobsd/
>This page contains information on developing FreeBSD to work in various
>small and unusual places, such as single floppy, vnode (vn(4))
>partitions or embedded controllers. Includes image for single floppy
>bootable Forth version.


PicoBSD is a version of FreeBSD that has been pruned and crunched to the bare minimum.
It includes scripts to tailor what you want to include. You can boot a diskless, 4 MB system from
a floppy and have a router and firewall. It will run on 386 and up hardware.

This is a full BSD Unix executive with virtual memory and BSD networking. There is a group
working on adding additional "small" utilities - small webserver, etc.

A thread on the PicoBSD mailing list has been discussing options for building a unified management
frontend. This begat the Forth effort, but there was discussion about other languages (TCL, Perl,
etc.).

Squeak and PicoBSD have been rolling around in my mind (lots of room) lately. Some thoughts:

- Squeak as a platform to build the PicoBSD frontend with:
I think that something that is text oriented is appropriate here. Remote access via telnet and
modems
on serial ports is important. Paul's embedded Squeak might be a good choice. Some of my concerns
are:
-- should you run in scripting mode where source is read, compiled and executed or
should you support saving images or some other format of compiled code.
[Python has a nice model for this].
-- how do you develop and debug. The Smalltalk development environment is very wedded to the
windowing environment.

- PicoBSD as the base of a Squeak only machine
If you are tempted to run a bare DOS version of Squeak, this is an interesting alternative. It is
completely
free with open source. 1.44 Megabytes will give you a running system with networking (ethernet,
ppp, slip...)
As for graphics - FreeBSD V3.0 (which PicoBSD is constructed from) included a new graphics library
that should be fine for porting Squeak to. It should be a lot lighter (memory and CPU cycles)
than using X.

What are the downsides?
-- It only supports x86 at the moment. There is an Alpha port substantially complete, but that's
it.
-- I think that the x86 machines that most people might be interested in dedicating too Squeak are
too slow
for doing interesting Squeak things. You still need a fast machine to run Morphic. If you want
to use
Squeak as a scripting engine (where the scripts are smalltalk source), then I think the compiler
is very,
very slow compared to other scripting languages.

-david

[Pennell's]

[Dredging into my memory, and anecdotal from a friend of mine...]

I think Sun uses (or at least used to) something like this.
It is based on Forth and is called OpenROM or something like that.
I believe that all the adapters had enough of a driver stored onboard
to support booting. It was supposed to be able to run on any of the
platforms they supported. I just did a quick search and found
references to OpenROM and OpenBoot. I believe that the guy
that wrote this is a pretty well know Forth personage.

Now the buzzword is I2O. Some believe this to be a plot by Intel
to sell more 960's since most (all) I20 adapters have a 960 onboard.
There is a lot of controversy over I2O in the Open Source camp.

-david
-----Original Message-----
From: Jan Bottorff <***@pmatrix.com>
To: ***@cs.uiuc.edu <***@cs.uiuc.edu>
Date: Saturday, December 26, 1998 7:11 PM
Subject: Re: SqueakOS


>At 09:32 AM 12/26/98 -0500, Paul Fernhout wrote:
>>I would imagine the big issue isn't getting something to boot -- it is
>>having a knowledge base for interacting with the variety of graphics
>>cards, ethernet cards, modems, SCSI adapters, HD drives, etc.
>
>I've recently had some interest in development of what I'd call a universal
>device driver spec. This would be a language or mabey just a framework for
>some current language that would allow hardware developers to specify
>drivers.
>
>Pretty much ALL device divers are currently written with the OS unique code
>mixed in with the device unique code. A very large part of developing a
>driver is understanding the hardware and the subtle ways to interact with
>it. I don't see any good reason why this knowledge can't be stored in a
>form that was totally platform/OS independent.
>
>The fantasy is the manufacturer of a piece of hardware could include a
>universal driver (in ROM or on disk). This driver would gurantee your
>hardware at least worked, on any OS that supported the universal driver
>model. This also would not stop companies from developing drivers highly
>tuned to specific device/OS combinations.
>
>It seems silly that a large amount of hardware is becoming unusable because
>the manufacturer is not expending software development effort to rewrite
>drivers for each new OS release. For example, many Win95/98 drivers will
>not work with Win 2000, and a BUNCH of hardware will become obsolete. It
>also seems like there is some real possibility of multiple OS's being
>significant on commodity hardware (Windows 98, Windows NT/2000, Linux,
>embedded OS's). Currently, each of these requires very different drivers.
>
>It occurs to me that Smalltalk might be an excellent tool for modeling this
>OS independence, either as some sort of compiler from universal driver
>format into OS/platform specific format (a driver source code generator) or
>as something more exotic (universal driver virtual machine or even
>compilation of universal driver source code into something executable on
>the fly).
>
>Right now, I'm in sortof a strategy phase, as in; am I crazy; could this
>actually be made to work; what is the very basic framework to make it work.
>
>On the plus side, I have lots of experience writing drivers and exotic
>run-time environments (like virtual machines). On the minus side, I don't
>believe anybody has done something like this (mabey there is a good
>reason), and I have to spend a large part of my time doing work for clients
>with better defined projects.
>
>It had occured to me hardware manufactures might be interested in funding
>the R&D effort, as it could bring enormous benefits to them down the road.
>Say forty hardware manufacturers put in $25k each, this would provide
>sufficent funds for a small team to make a very serious run at the problem.
>My sense is $25k is a drop in the bucket if your primary task is designing
>a new peripheral device. I'd think the R&D costs for a single printer from
>somebody like HP must be millions of dollars.
>
>The issue of device drivers is a serious problem across many projects, from
>Windows to Linux to embedded Smalltalk. I personally believe solutions much
>better than are currently available would be possible.
>
>Jan Bottorff, President
>Paradigm Matrix, Inc.
>
>___________________________________________________________________
> Paradigm Matrix Inc., San Ramon California
> "video products and development services for Win32 platforms"
>Internet: Jan Bottorff ***@pmatrix.com
> WWW http://www.pmatrix.com
>Phone: voice [phone]
> fax [phone]
>PGP: public key <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>
> fingerprint 52 CB FF 60 91 25 F9 44 6F 87 23 C9 AB 5D 05 F6
>___________________________________________________________________
>
>

[William Barnett-Lewis]

Well, I have noticed that the best of the crop of these little machines
(i.e. HP's new color HP800 series) have a user "upgradable" ROM. The
HP800, for example, specs says "16MB Burst Mode ROM, user upgradable".
All you would need is the Strong Arm port of Linux, Squeak, and a
compatible ROM for burning...

Now this assumes a bit better HW hacker than I, but it really shouldn't
be that difficult to liberate what otherwise seems like a very nice
machine.

(The HP800 can be found at
http://www.hp.com/jornada/palmtops/hp800/800_overview.html )

William


Patrick Logan wrote:
>
> But my real interest in a portable OS is for hardware like the
> latest crop of WinCE machines which don't have hard disks. They
> boot from a ROM that's probably soldered to the board. How can one
> "take over" such a machine with a custom OS? It could be
> impossible, especially if the OS in ROM turns on memory
> protection.
>
> I think this hard-wiring is intentional. Richard Stallman had an
> article about it in a CACM issue a year or so ago. The architecture of
> WinCE hardware and software has been seen by several people as an
> attempt by Microsoft to:
>
> (1) Wrestle hardware control away from Intel; and
>
> (2) Wrestly software control away from alternate OSs like NeXT, BeOS,
> Linux, Solaris on Intel, etc. that were just starting to show
> signs of life back when WinCE emerged.
>
> But this has never stopped those amazingly creative software hackers
> before, has it?
>
> --
> Patrick Logan mailto:***@gemstone.com
> Voice 503-533-3365 Fax [phone]
> Gemstone Systems, Inc http://www.gemstone.com

--
Live without fear; your Creator loves you
as a mother. Go in peace to follow the good
road and may God's blessing be with you always.
St. Claire

[Patrick Logan]

But my real interest in a portable OS is for hardware like the
latest crop of WinCE machines which don't have hard disks. They
boot from a ROM that's probably soldered to the board. How can one
"take over" such a machine with a custom OS? It could be
impossible, especially if the OS in ROM turns on memory
protection.

I think this hard-wiring is intentional. Richard Stallman had an
article about it in a CACM issue a year or so ago. The architecture of
WinCE hardware and software has been seen by several people as an
attempt by Microsoft to:

(1) Wrestle hardware control away from Intel; and

(2) Wrestly software control away from alternate OSs like NeXT, BeOS,
Linux, Solaris on Intel, etc. that were just starting to show
signs of life back when WinCE emerged.

But this has never stopped those amazingly creative software hackers
before, has it?

--
Patrick Logan mailto:***@gemstone.com
Voice 503-533-3365 Fax [phone]
Gemstone Systems, Inc http://www.gemstone.com

[johnm at wdi.disney.com ()]

Dwight Hughes <***@ipa.net> wrote:
> Also be sure to take a close look at the Flux OSKit version 0.96 just
> released:
>
> http://www.cs.utah.edu/projects/flux/oskit/
>
> You can create very small "kernels" with just the resources required and
> wrapper code from other unixy OSs.

Interesting! How portable is OSKit?

I know that Compaq is running a stripped down Linux on their Itsy
Palmtop prototype. I believe it uses about 4 MBytes, comparable the
the stripped-down FreeBSD (PicoBSD) that David Pennell mentioned.

Squeak doesn't need much from an OS: a display driver, a millisecond
clock, and a pointing device driver are the minimum; everything else
is optional including a file system and keyboard input. (Support for
some sort of interrupt key or button is quite helpful.) I know of at
least two bare-hardware Squeak ports. Writing drivers for the basic
display and pointing devices is not too difficult. Adding support for
a file system, sound output and input, and/or serial ports is also
straightforward. The one thing I would be loathe to tackle is a TCP/IP
protocol stack. So, for me, networking is the most compelling feature
that these micro OS's offer.

Unfortunately, just having a portable OS kernel may not be sufficient.
The hardware details required to port the OS to a given device
may not be published, or the existing OS may use a memory
protection scheme that that makes it impossible to supplant it
with a new OS.

Still, I'd love to see more bare-machine Squeak ports, and I'd
be happy to see Squeak ported to one of these micro OS kernels.

-- John

[Dwight Hughes]

The main limitation to portability is all the x86 low-level code that
handles the general hardware setup and initialization grunge that brings
everything up from "real" mode to protected mode and all the other gory
details - but taking care of this level of grunge is what the OSKit is
all about. It is intended to be portable, but only the x86 version is
available right now (IMO it should be reasonably straightforward to
translate the x86-specific portions to another processor architecture --
the whole design seems to be quite well factored, and someone with
decent low-level Linux/*BSD kernel hacking skills should be able to
adapt a lot of the work already done in other ports). The OSKit uses all
its own C libraries under gcc - so the bulk of the system is portable to
whatever processors gcc has been ported to. Online doc is available at:
http://www.cs.utah.edu/projects/flux/oskit/doc/
The libraries included with the OSKit seem to cover everything needed to
support a _full_ Squeak port (networking, filesystem, multithreading,
virtual memory, windowing, keyboard, mouse support, etc) except for
sound support. Right now only the XFree86 S3 driver is included for
windowing hardware support (this "includes all video hardware supported
by the XF86_S3 server") - I think you need to use their WIMPi window
manager with this to get the support needed for Squeak (should be a
fairly light-weight solution).

One commercial system based on an earlier much less factored version of
OSKit (version 0.60 IIRC) is Network Storage Solutions' high-performance
SPANstor network storage server OS. They have a full demo that you can
boot and run from a single floppy (I don't know if they mention that
their design is based on the OSKit on their site, but they sent an
announcement to the OSKit mailing list about it a while back).
http://www.nssolutions.com/

Since the OSKit can wrapper most hardware drivers from FreeBSD/NetBSD
and such, one can take advantage of a lot of work done by others. The
video drivers seem to be the real sticking point - it would be nice to
have much more modular drivers available (perhaps the GGI project
will help with this).

-- Dwight

***@wdi.disney.com wrote:
>
> Dwight Hughes <***@ipa.net> wrote:
> > Also be sure to take a close look at the Flux OSKit version 0.96 just
> > released:
> >
> > http://www.cs.utah.edu/projects/flux/oskit/
> >
> > You can create very small "kernels" with just the resources required and
> > wrapper code from other unixy OSs.
>
> Interesting! How portable is OSKit?
>
> I know that Compaq is running a stripped down Linux on their Itsy
> Palmtop prototype. I believe it uses about 4 MBytes, comparable the
> the stripped-down FreeBSD (PicoBSD) that David Pennell mentioned.
>
> Squeak doesn't need much from an OS: a display driver, a millisecond
> clock, and a pointing device driver are the minimum; everything else
> is optional including a file system and keyboard input. (Support for
> some sort of interrupt key or button is quite helpful.) I know of at
> least two bare-hardware Squeak ports. Writing drivers for the basic
> display and pointing devices is not too difficult. Adding support for
> a file system, sound output and input, and/or serial ports is also
> straightforward. The one thing I would be loathe to tackle is a TCP/IP
> protocol stack. So, for me, networking is the most compelling feature
> that these micro OS's offer.
>
> Unfortunately, just having a portable OS kernel may not be sufficient.
> The hardware details required to port the OS to a given device
> may not be published, or the existing OS may use a memory
> protection scheme that that makes it impossible to supplant it
> with a new OS.
>
> Still, I'd love to see more bare-machine Squeak ports, and I'd
> be happy to see Squeak ported to one of these micro OS kernels.
>
> -- John

[johnm at wdi.disney.com ()]

Thanks for the interesting info and pointers.

The one thing I wonder about is how you get something like OSKit to boot
instead of Win 95. On a machine with a disk, it may be merely a matter
of changing the boot blocks of the disk. But my real interest
in a portable OS is for hardware like the latest crop of WinCE machines
which don't have hard disks. They boot from a ROM that's probably
soldered to the board. How can one "take over" such a machine with
a custom OS? It could be impossible, especially if the OS in ROM turns
on memory protection.

The Compaq Itsy is nice because it is a semi-open hardware platform.
They give all the hardware specs you need to write drivers, and they
have a way to load new OS kernels into the boot "ROM" (Flash RAM,
actually). Unfortunately, this is still a research project and Itsy's
are not available unless you happen to be at one the Universities
that they are collaborating with.

-- John

[Steve Dekorte]

Another possible microkernel for SqueakOS:

http://www.chat.net/~jeske/VSTa/index.html

Here's a brief description from the site:

VSTa is quite different than your typical free UNIX. First, it does not even try to be exactly a UNIX; areas which have proven to be problematic for extensibility or efficiency have been changed. For instance, signals are strings, as are error numbers. Thus, VSTa is much more of a platform for experimentation with beyond UNIX ideas than simply another implementation of UNIX.

The other major difference from "classic UNIX" is that VSTa is a microkernel. The microkernel provides messaging, processes, and virtual memory. All filesystems and device drivers run as user-level tasks. The kernel is 40K, and has remained at this size for quite a while, while the system as a whole has gained significant functionality...

[Marcus Denker]

On Mon, Oct 11, 1999 at 07:43:25AM -0800, Dan Ingalls wrote:

> What VM did you start with?
>
The VM is based on Embedded Squeak (by Paul Fernhout,
http://www.kurtz-fernhout.com/squeak/).

Embedded Squeak is a 2.2 VM with most drivers removed: no Sound,
network, IO, graphics. Only the Serial-Port-access is implemented.
It uses a non-inlined interp.c.
I have changed the Serial-Port Primitves to do STDIN/OUT on Unix.

Paul implemented a simple way of embedding the image in the VM:
The image contains code to write it into a C-Array.
sqImageFileRead() is changed to read the image from this array.

The downside of this approach is that the memory used by this array
is not freed later.

> What image did you start with?
>
It's the image that comes with Embedded Squeak. It seems to be the
2.2 "mini.image" with some additions, like the command-line parsing.

>
> Is your file smaller because of compression?
>
Yes. Oskit builds Kernel-Images in a format called "MultiBoot". This
can be converted to many others, including the format of the Linux kernel.

My SqueakOS-kernel uses the LinuxKernel-image format: It is compressed with
gzip, and automatically decompresses itself on startup. The size of
this startup-code and decompressor:
-rwxr-xr-x 1 marcus marcus 45528 Oct 10 10:32 linuxboot.bin*

The "MultiBoot" image without Linux-booter, uncompressed:

-rwxrwxr-x 1 marcus marcus 832272 Oct 10 22:15 esqueak*

***@wombat:~/proj/squeakOS $ size esqueak
text data bss dec hex filename
207276 608904 97748 913928 df208 esqueak

The .o-files of the VM:
***@wombat:~/proj/squeakOS $ size *.o
text data bss dec hex filename
0 602900 0 602900 93314 ImageFileInMemory.o
112188 4 0 112192 1b640 interp.o
5854 12 256 6122 17ea sqEmbedded.o
401 4 0 405 195 sqFilePrims.o
3854 0 0 3854 f0e sqMiscPrims.o

Explanation:
text: the binary programm text
data: initialized data (like global arrays))
bss: uninitialized data, this is not contained in the executable
but allocated (and initialied with 0) when the programm is
started.
While running the programm can additionally allocate memory. This is
normally done via "malloc()".
(a good explanation of this can be found in W. Richard Stevens:
"Programming in the Unix Environment")

>
> What is the final "footprint" -- meaning, when squeak is running,
> executing something from the command, how much space do flux, the
> vm and the image each take up, roughly, and how much free space do
> you typically allocate for free space in the object memory?
>

The footprint seems to be somewhat like this:

Linux Startup-Code: 45528
text+data+bss VM: 122573
data Image-Array: 602900

The rest has to be the memory of OSKit (and the c-library of OSKit):

data+text+bss: 188455

Now the VM allocates some memory via "malloc", "availablememory"
is set to 1850000 in sqEmbedded.c, so:

ObjectMemory: 1850000
---------------
2,809,456 byte used memory

"Smalltalk bytesLeft" returns "1103476".

--
Marcus Denker ***@ira.uka.de ***@home:[phone] @work:[phone]

[Edward P Luwish]

Marcus Denker wrote:

[re: MiniSqueak2.2 image]

Hmm. I assume it needs a full VM, though. Does it work with 2.4 or 2.5?
For headless work, is it possible to strip out a bunch of primitives and any resulting dead code so the VM can be as small as possible? Or is this a problem left for the
reader :-)
I suppose the current work on dynamically-loadable images and a modular VM may answer this requirement (or maybe not).
[By headless I mean with a command-line workspace, not an embedded application like a PWS]

The reason I am asking is that as the VM becomes more complex (e.g., incorporates a JIT compiler), porting becomes far more difficult. It would help if there were a subsetting
of the VM so that manageable pieces can be debugged one at a time (or by more than one developer).

Ed

[Marcus Denker]

Hi!

I played with "The OSKit" (http://www.cs.utah.edu/flux/oskit/) this
weekend.

The result is a bootable VM (x86 only), based on EmbeddedSqueak.
Text-mode command-line only, I've put a diskimage of a bootable
1.44MB floppy at http://www.ira.uka.de/~marcus/SqueakOS.image.gz

zip: http://www.ira.uka.de/~marcus/SqueakOS.image.zip
Source: http://www.ira.uka.de/~marcus/SqueakOS-src.tar.gz

Building the Boot-disk:

Linux: dd if=SqueakOS.image of=/dev/fd0
DOS/Win: use rawrite, ftp://ftp.ira.uka.de/pub/squeak/demo/rawrite2.exe

The SqueakOS-Kernel is only 440K:

-rw-rw-r-- 1 marcus marcus 454619 Oct 10 22:15 zImage

This includes the 600k embedded.image!

Marcus

--
Marcus Denker ***@ira.uka.de ***@home:[phone] @work:[phone]
The Difference between today and yesterday is not so much what has changed
between then and now as what I hope to change by tomorrow.

[Marcus Denker]

On Wed, Oct 13, 1999 at 06:30:47PM -0300, Alejandro Weil wrote:
> Dan Ingalls wrote:
>
> > I once made up a Squeak image that was ony 250K for headless work (it would probably be hard to get down to that now, though). Anyway it's still on a server somewhere.
> >
>
> Where can I download a small image with graphics support?

Mini.image (2.2): (584k)
---------
ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/SmallSqueaksForPDAs/MiniSqueak2.2/

This is a MVC-only image (no Morphic), it includes a complete
developement-environment (editor, compiler, source code browsers,
fileLists...)

The directory "MakeYourOwn" contains all code that Dan used to build
the mini.image from the normal 2.2 release.


Marcus

--
Marcus Denker ***@ira.uka.de ***@home:[phone] @work:[phone]
Imitating paper on a computer screen is like tearing the wings off a 747 and
using it as a bus on the highway. -- Ted Nelson

[Dan Ingalls]

Edward P Luwish <***@uswest.com> wrote...
>The reason I am asking is that as the VM becomes more complex (e.g., incorporates a JIT compiler), porting becomes far more difficult. It would help if there were a subsetting
>of the VM so that manageable pieces can be debugged one at a time (or by more than one developer).

This need not be the case. Ian's current plan with Jitter is actually to SIMPLIFY the bytecode engine, thus hopefully easing the porting process. JITTER is built as a plug-in, so it neither complicates the VM significantly, nor adds space for minimal implementations. Once the basic engine is running, one can go on to the JITTER as a separate project.

- Dan

[Dan Ingalls]

>The SqueakOS-Kernel is only 440K:
>
>-rw-rw-r-- 1 marcus marcus 454619 Oct 10 22:15 zImage
>
>This includes the 600k embedded.image!

Marcus -

This sounds great.

I assume your system is a minimal Squeak image bundled with a VM that was linked in with the OSKit.

My questions...

What image did you start with?

I once made up a Squeak image that was ony 250K for headless work (it would probably be hard to get down to that now, though). Anyway it's still on a server somewhere.

What VM did you start with?

Is your file smaller because of compression?

If so, is this done so that the boot file on the disk is compressed and it expands during loading?

What is the final "footprint" -- meaning, when squeak is running, executing something from the command, how much space do flux, the vm and the image each take up, roughly, and how much free space do you typically allocate for free space in the object memory?

Thanks in advance for any enlightenment you can give.

- Dan

[Alejandro Weil]

Dan Ingalls wrote:

> I once made up a Squeak image that was ony 250K for headless work (it would probably be hard to get down to that now, though). Anyway it's still on a server somewhere.
>

Where can I download a small image with graphics support?
I made one with 900kb aprox.

Thank You
ale

--- For a personal reply use ***@core-sdi.com

[Dan Ingalls]

>On Wed, Oct 13, 1999 at 06:30:47PM -0300, Alejandro Weil wrote:
>> Dan Ingalls wrote:
>>
>> > I once made up a Squeak image that was ony 250K for headless work (it would probably be hard to get down to that now, though). Anyway it's still on a server somewhere.
>> >
>>
>> Where can I download a small image with graphics support?

Marcus Denker <***@ira.uka.de> replied:
>Mini.image (2.2): (584k)
>---------
>ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/SmallSqueaksForPDAs/MiniSqueak2.2/
>
>This is a MVC-only image (no Morphic), it includes a complete
>developement-environment (editor, compiler, source code browsers,
>fileLists...)
>
>The directory "MakeYourOwn" contains all code that Dan used to build
>the mini.image from the normal 2.2 release.

Also, I found the "headless" image that I made up back in 1997. It is 245K, and vintage 1.21. It runs fine with a 1.21 or 2.2 VM. Most important, all the files are there in the Squeak/tiny/tinySqueak.sea.hqx' on UIUC. In particular, there's a readme file that begins as follows...
---------------------
This file describes the files and processes involved in producing a first cut at a headless (without UI) Squeak. It is assumed that you will begin with the file Mini1.21.image, a Squeak that has already had most unnecessary classes and methods removed. You can produce essentially the same starting point yourself by starting with Squeak-1.21 (or Squeak-1.2 plus FileIn-1.21-di.cs) and executing Smalltalk majorShrink.

The end result of the headless shrink procedure is a Squeak image that is 246K in size, containing 110 classes and 1771 methods. These include the core classes and methods for Numbers, Collections, Compiler and File System, so that you can still open files, execute simple fileIns and quit.
---------------------
My guess is that a week's work would get you back down under 300K from Squeak 2.6 following the same prescription.

- Dan

[Derek Brans]

How difficult would it be to turn Squeak into an OS? Has there been any
discussion / papers about this that someone can point me to?

Thanks,
Derek

Phasecraft: Smarter Web Development.
Experts in web design, databases, flash design, multi-lingual sites,
branding, marketing and web hosting.
phone: [phone]
mailto:***@phasecraft.com
http://www.phasecraft.com

[Jecel Assumpcao Jr]

On Wednesday 02 October 2002 14:06, Derek Brans wrote:
> How difficult would it be to turn Squeak into an OS? Has there been
> any discussion / papers about this that someone can point me to?

Check out http://sourceforge.net/projects/squeaknos/ and
http://mathmorphs.swiki.net/9

Did you know that before Digitalk introduced Methods (later Smalltalk/V)
for PCs running DOS in 1985, Smalltalk was always implemented on the
raw hardware?

"Operating System: An operating system is a collection of things that
don't fit into a language. There shouldn't be one."
Daniel H H Ingalls in "Design Principals Behind Smalltalk", August
1981 issue of Byte Magazine, pages 286 to 298

-- Jecel

[Tim Rowledge]

Derek Brans <***@phasecraft.com> is claimed by the authorities to have written:

> How difficult would it be to turn Squeak into an OS? Has there been any
> discussion / papers about this that someone can point me to?
At Interval Research we made a realtime OS out of Squeak. Seemed
promising, which of course is why it was canned in favour of WinCE. A
just about readable copy of my OOPSLA 99 paper on the system is at
http://sumeru.stanford.edu/tim/pooters/RTOSinSmalltalk.html

tim
--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Computer Science: solving today's problems tomorrow.

[Daniel Joyce]

>
> At Interval Research we made a realtime OS out of Squeak. Seemed
> promising, which of course is why it was canned in favour of WinCE. A
> just about readable copy of my OOPSLA 99 paper on the system is at
> http://sumeru.stanford.edu/tim/pooters/RTOSinSmalltalk.html
>
> tim

And of course, this wonderful code is buried somewhere to never be used
again. The wonders of propietary closed source software. Interval has
donated some things, but if they didn't want to use a RTOS Squeak, what
makes them think someone else ever will? ( Why hold on to dead project
code? No one is gonna buy it! Set it free! ).

RTOS Squeak now moulders on a musty tape somewhere with NEWS and other
innovative software that people could learn from... Heck, they managed
to talk SUN into releasing SELF, and SUN is still around... <:)

This is something the squeak community could really use ( along with a
robust clean widget set in the image, last time I looked, Prefab is not
included, and the morphic widgets are all half-implemented or
excessively hairy). This would go a long ways to help making Squeak
very very very very useful for more than just one-off demos and
presentation eye-candy. I play with Squeak alot, but I bang my head
against it sometime.

Will we ever see the light of this stuff from Interval? Could we buy it?
I mean, the users of Blender bought the source code out, and open
sourced it. Could we do the same? Is there a price?

I'll put $250 where my mouth is on this issue.

-Daniel

[Craig Latta]

Daniel writes:

> And of course, this wonderful code is buried somewhere to never be
> used again.

short answer: It's not as bad as that.

long answer:

I'm sure the following is in the Google archives somewhere, but
I'm too lazy to look it up... anyone please feel free to correct me.

I was on the Interval Smalltalk team. Our system was part of a
local media network system (homes, cars, etc.) which used a novel
networking protocol ("MediaWire") that was cheap (ran over phone wire),
synchronous, could support variable bitrates, and was, for the time,
fast (100Mb). We worked on the "MediaPad", a sort of glorified remote
control, a letter-sized touchscreen device with which you could control
all the connected devices, make new composite devices, etc. It was
similar in appearance to the failed crop of "web pads" which kept
appearing later :). Tim and I showed off a couple of them at OOPSLA '99.
I designed the device driver framework (a precursor to Flow).

At the end of the project, we got permission to release all the
non-MediaWire-specific software (pretty much the whole virtual machine,
and most of the object memory). The catch is that only two of us had
working MediaPad-building environments at the end (the end came
suddenly). A different two of us (Tim and myself) had working MediaPads.
Unfortunately, we've never been motivated enough collectively to get all
the bits and hardware back together. Doing so would be some non-trivial
amount of work, and we've all been busy with other things since. I
actually have been releasing parts of the object memory over time,
starting with the exception-handling framework I wrote (when Squeak
didn't have one), then moving on to the device stuff. It's generally
slow going though, because writing and performing music always gets more
of my time.

I expect the complete system would take a non-trivial amount of
rework to retarget to different hardware. The MediaPad was always a
home-grown prototype (based on the StrongARM 1100, and custom ASICs, at
no small cost). The native code generator wouldn't be immediately useful
to all Squeakers, for example. Some of the ARM development tools we used
are not open-source. Another problem not to be underestimated is that
both Tim and I have so far been too paranoid to attempt rewriting either
of the MediaPad ROMs, for fear of the population of known demo-able
MediaPads dropping by half. :) Also, the system got basic testing, but
the project died before we could really pound it in actual homes.

Anyway, the software is not closed as far as I know, but it's
not in a state where it can meaningfully be distributed as a single
coherent system. I think it's fair to say that most of us wouldn't feel
right distributing something that people can't just fire up and use
(leftover pride I suppose :). That mostly explains why the occasional
"why doesn't the Interval Smalltalk system get released?" query is met
with relative silence.

I've always wanted to eventually get the whole thing released,
though, and I plan to keep at it. I think a proper revival of the
project would be a lot of fun and still very useful, too, but we'd have
to solve the hardware environment problem first. I'm game. :)

John writes:

> The Interval project was a special case. They were building their
> own custom hardware, so they HAD to write their own device drivers...

Well, that was just the MediaPad and assorted networking glue
(standalone clocks, hubs, etc.); the situation was a little more...
interesting. Part of the plan was to collaborate with the major consumer
electronics firms to establish MediaWire as a common interconnection
technology (e.g., you'd find MediaWire ports on next-generation TVs, CD
players, etc.). We were going for all the traditional closed-spec
devices in addition to our own stuff, by being part of the specs. It was
Big. :) The Japanese financial crisis in 1998 took most of the wind out
of those sails (the biggest potential collaborators were deeply
affected). I tend to agree with Tim that Mr. Bill finished it off.

> ...and they had a large team of both hardware and software engineers.

It wasn't that large, really. The comparison we liked to bat around was
the fifteen of us versus the thousand people developing WinCE. :)

Tim writes:

> I'm pretty much convinced [implementing everything, including device
> drivers, in Smalltalk] isn't really worth it. At least, not unless
> one can fairly seriously rejig things to provide useful OS type
> facilities like protection of one application's memory from another,
> all that stuff.

Indeed... and I thought we were well on our way. :) I thought having
everything written in Squeak was fantastic. It made debugging things
easier, and it was much simpler to explain the overall system
architecture to newcomers. It afforded a great deal of useful technical
control. And it was just more fun, which does have value.

At the same time, I'm all for creating the illusion of object memory
anywhere it's useful, including OSKit and the "commodity" OS platforms.
The trick is where to stop... in Interval's case, there were very good
technical and business reasons for "going deep". Most of the time, as a
single individual with a limited lifespan, I'm content to get on with
higher priorities as long as the supporting stuff isn't too distracting.

> I agree with Dan's old aphorism about the OS but I think a better
> interpretation of it is that nothing in the OS should be unreachable
> from your language - not that there shouldn't be the OS there at all.

To a large degree I view The Aphorism as a statement of that time, when
the technology wasn't as pervasive and things were more open to change.
And somewhere there should be a footnote: "Things get weird when
billionaires are nearby." :)


-C

--
Craig Latta
improvisational musical informaticist
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]

[Tommy Thorn]

Craig,

thanks a lot for the most interesting account

> I expect the complete system would take a non-trivial amount of
>rework to retarget to different hardware. The MediaPad was always a
>home-grown prototype (based on the StrongARM 1100, and custom ASICs, at
>no small cost). The native code generator wouldn't be immediately useful
>to all Squeakers, for example.
>

The ARM is pretty big in the embedded space. Did the ASIC provide
functionality crucial for the native implementation of Smalltalk on
StrongARM?

Not that I'm suggesting it, but FPGAs have progressed significantly in
recent years. Yesterdays ASICs might be reimplementable with todays
FPGAs (at a considerbly lower NRE cost).

> I've always wanted to eventually get the whole thing released,
>though, and I plan to keep at it. I think a proper revival of the
>project would be a lot of fun and still very useful, too, but we'd have
>to solve the hardware environment problem first. I'm game. :)
>

Again, what special hardware support is needed? Object memory like on
the Newton?

All the best,

Tommy

[Tim Rowledge]

Tommy Thorn <***@meko.dk> is claimed by the authorities to have written:

> The ARM is pretty big in the embedded space. Did the ASIC provide
> functionality crucial for the native implementation of Smalltalk on
> StrongARM?
Well, yes - it provided the interface to memory and the LCD panel etc
since there were no commercial support chips at the time the h/w was
designed. These days one would probably just buy a standard part or
maybe even go with the SA1110 instead, which has most of it onchip.
>
> Not that I'm suggesting it, but FPGAs have progressed significantly in
> recent years. Yesterdays ASICs might be reimplementable with todays
> FPGAs (at a considerbly lower NRE cost).
If you were thinking of some magical hardware interpreter, forget it.
Completely pointless unless you're doing it for fun or longterm
research. Much better to put the effort into a good translation system
to make good use of plain ol'vendor parts that will be twice as fast and
half the price by the time you have it done. Don't fight Moore's Law.

> Again, what special hardware support is needed? Object memory like on
> the Newton?
Bandwidth. Big onchip cache (128Mb would be nice :-) More bandwidth.
Very fast interrupt handling (ARM does this part well).

tim

--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: SOD: Scribble On Disk

[Tommy Thorn]

Tim Rowledge wrote:

>>Not that I'm suggesting it, but FPGAs have progressed significantly in
>>recent years. Yesterdays ASICs might be reimplementable with todays
>>FPGAs (at a considerbly lower NRE cost).
>>
>>
>If you were thinking of some magical hardware interpreter, forget it.
>

I'm not thinking of anything, just replying to your comments about
custom hardware which used expensive ASICs.

You said that the native code compiler wouldn't be useful for most
people and I was asking if it required special hardware support, or if
the reason it wasn't useful was simply that most people don't have ARMs.

>Completely pointless unless you're doing it for fun or longterm
>research. Much better to put the effort into a good translation system
>to make good use of plain ol'vendor parts that will be twice as fast and
>half the price by the time you have it done. Don't fight Moore's Law.
>

I never said anything like that. I was refering to replacing your ASICs.

However, now that you brought it up, making a hardware (FPGA)
implementation of Smalltalk would indeed be fun (it looks like Jercel is
doing that) and it *might* make sense in some settings. Why do you think
Xilinx and Altera spend millions to develop their softcores (MicroBlaze?
and Nios respectively) when obviously their performance can't reach that
of a substantially cheaper of-the-shelf part? Softcores make sense for
example for an embedded device where board space is at a premium and
there already is a substantiel need for custom logic.

Of course for a custom general purpose system there really is no way to
beat the performance of a $100 x86 chip.

>>Again, what special hardware support is needed? Object memory like on
>>the Newton?
>>
>>
>Bandwidth. Big onchip cache (128Mb would be nice :-) More bandwidth.
>Very fast interrupt handling (ARM does this part well).
>
>

What special hardware support did the _Interval_Smalltalk_ require was
what I meant. The StrongARM doesn't exactly have bandwidth nor big
on-chip caches and the MediaPad's custom (external) ASIC clearly didn't
implement a big cache.

For utmost bandwidth buy a P4 and fit it with 533 Mhz Rambus memory, but
then we're obviously out of the embedded space. StrongARM is probably a
bad choice anyway if you're seriously concerned about bandwidth.

/Tommy

[Tim Rowledge]

Tommy Thorn <***@meko.dk> is claimed by the authorities to have written:

> Tim Rowledge wrote:
>
> >>Not that I'm suggesting it, but FPGAs have progressed significantly in
> >>recent years. Yesterdays ASICs might be reimplementable with todays
> >>FPGAs (at a considerbly lower NRE cost).
> >>
> >>
> >If you were thinking of some magical hardware interpreter, forget it.
> >
>
> I'm not thinking of anything, just replying to your comments about
> custom hardware which used expensive ASICs.
I hope I didn't make it sound like I was 'getting at' you in any way!
Your remarks stirred up a recollection of the almost innumerable times
that I've heard someone suggest that all that is needed is a special cpu
to execute bytecodes and all would be well; something that simply isn't
even vaguely true and has in fact been tried on several occasions to no
good effect. Just for starters, there are minor things like primitives
and memory management that don't have much use for bytecode interpreting
hardware.
>
> You said that the native code compiler wouldn't be useful for most
> people and I was asking if it required special hardware support, or if =20
> the reason it wasn't useful was simply that most people don't have ARMs.
Oh, I don't think that's quite I intended. The native code compiler we
made at Interval was (is) able to output C source code, ARM assembler
text or ARM object code ready to run. Alan Purdy (for it is he that
wrote 90+% of it) asserts that it would be fairly simple to retarget the
assembler output to any cpu. No special hardware was harmed in the
creation of the compiler. Several people have grabbed copies to look at
it and I think at least one person has decided to take their own hack at
the concept. Note that it was not very much to do with the core vm but
rather intended to compile device drivers delivered on the fly by
devices added to the net that the Trio pad was acting as controller for.

> However, now that you brought it up, making a hardware (FPGA)
> implementation of Smalltalk would indeed be fun (it looks like Jercel is
> doing that) and it *might* make sense in some settings. Why do you think
> Xilinx and Altera spend millions to develop their softcores (MicroBlaze?
> and Nios respectively) when obviously their performance can't reach that
> of a substantially cheaper of-the-shelf part? Softcores make sense for =20
> example for an embedded device where board space is at a premium and
> there already is a substantiel need for custom logic.
Exactly; a very special case where the financial logic pushes the other
way to 'normal' desktop machines. Jecel is one ofthe very very small
number of peopleI belive could even come close to making special purpose
hardware actually deliver. SUN tried at least acouple of times for java
nad seem to have failed. SOAR was not very effective, Sword/32 failed,
iAPX432 was a dog, etc etc. None of which means that nobody will ever
suceed, it just means I won't be putting any of my millions into the
project.

>
> Of course for a custom general purpose system there really is no way to
> beat the performance of a $100 x86 chip.
Sad, isn't it?
> What special hardware support did the _Interval_Smalltalk_ require was =20
> what I meant. The StrongARM doesn't exactly have bandwidth nor big
> on-chip caches and the MediaPad's custom (external) ASIC clearly didn't
> implement a big cache.
No special hardware at all from the point of view of the Smalltalk. The
nearest part you could point at was the video memory controller where I
persuaded the hardware team make it such that I could write to control
registers to set the addresses where the display bits would live, rather
than having to tolerate whatever somebody else wanted. That meant I
could have the screen buffer in ordinary object memory space.
SA has pathetic onchip caches (which is annoying since the cpu core
occupies less that 50k gates and could fit in the top left corner of a
big ram chip in any decently organised world) but does have
reasonable memory bandwidth given its market. ARM10 & 11 are much
better. If somebody would up the money it would be most enjoyable to
build something from them.


tim
--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: MII: Mask all Interrupts and then Interrupt

[Tim Rowledge]

Tommy Thorn <***@meko.dk> is claimed by the authorities to have written=
:

> Tim Rowledge wrote:
>=20
> >>Not that I'm suggesting it, but FPGAs have progressed significantly i=
n=20
> >>recent years. Yesterdays ASICs might be reimplementable with todays=20
> >>FPGAs (at a considerbly lower NRE cost).
> >> =20
> >>
> >If you were thinking of some magical hardware interpreter, forget it.
> >
>=20
> I'm not thinking of anything, just replying to your comments about=20
> custom hardware which used expensive ASICs.
I hope I didn't make it sound like I was 'getting at' you in any way!
Your remarks stirred up a recollection of the almost innumerable times
that I've heard someone suggest that all that is needed is a special cpu
to execute bytecodes and all would be well; something that simply isn't
even vaguely true and has in fact been tried on several occasions to no
good effect. Just for starters, there are minor things like primitives
and memory management that don't have much use for bytecode interpreting
hardware.
>=20
> You said that the native code compiler wouldn't be useful for most=20
> people and I was asking if it required special hardware support, or if ==20
> the reason it wasn't useful was simply that most people don't have ARMs=
.
Oh, I don't think that's quite I intended. The native code compiler we
made at Interval was (is) able to output C source code, ARM assembler
text or ARM object code ready to run. Alan Purdy (for it is he that
wrote 90+% of it) asserts that it would be fairly simple to retarget the
assembler output to any cpu. No special hardware was harmed in the
creation of the compiler. Several people have grabbed copies to look at
it and I think at least one person has decided to take their own hack at
the concept. Note that it was not very much to do with the core vm but
rather intended to compile device drivers delivered on the fly by
devices added to the net that the Trio pad was acting as controller for.

> However, now that you brought it up, making a hardware (FPGA)=20
> implementation of Smalltalk would indeed be fun (it looks like Jercel i=
s=20
> doing that) and it *might* make sense in some settings. Why do you thin=
k=20
> Xilinx and Altera spend millions to develop their softcores (MicroBlaze=
=99=20
> and Nios respectively) when obviously their performance can't reach tha=
t=20
> of a substantially cheaper of-the-shelf part? Softcores make sense for ==20
> example for an embedded device where board space is at a premium and=20
> there already is a substantiel need for custom logic.
Exactly; a very special case where the financial logic pushes the other
way to 'normal' desktop machines. Jecel is one ofthe very very small
number of peopleI belive could even come close to making special purpose
hardware actually deliver. SUN tried at least acouple of times for java
nad seem to have failed. SOAR was not very effective, Sword/32 failed,
iAPX432 was a dog, etc etc. None of which means that nobody will ever
suceed, it just means I won't be putting any of my millions into the
project.

>=20
> Of course for a custom general purpose system there really is no way to=
=20
> beat the performance of a $100 x86 chip.
Sad, isn't it?
> What special hardware support did the _Interval_Smalltalk_ require was ==20
> what I meant. The StrongARM doesn't exactly have bandwidth nor big=20
> on-chip caches and the MediaPad's custom (external) ASIC clearly didn't=
=20
> implement a big cache.
No special hardware at all from the point of view of the Smalltalk. The
nearest part you could point at was the video memory controller where I
persuaded the hardware team make it such that I could write to control
registers to set the addresses where the display bits would live, rather
than having to tolerate whatever somebody else wanted. That meant I
could have the screen buffer in ordinary object memory space.
SA has pathetic onchip caches (which is annoying since the cpu core
occupies less that 50k gates and could fit in the top left corner of a
big ram chip in any decently organised world) but does have
reasonable memory bandwidth given its market. ARM10 & 11 are much
better. If somebody would up the money it would be most enjoyable to
build something from them.


tim
--=20
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: MII: Mask all Interrupts and then Interrupt

[Tommy Thorn]

Tim Rowledge wrote:

>>Not that I'm suggesting it, but FPGAs have progressed significantly in=20
>>recent years. Yesterdays ASICs might be reimplementable with todays=20
>>FPGAs (at a considerbly lower NRE cost).
>> =20
>>
>If you were thinking of some magical hardware interpreter, forget it.
>

I'm not thinking of anything, just replying to your comments about=20
custom hardware which used expensive ASICs.

You said that the native code compiler wouldn't be useful for most=20
people and I was asking if it required special hardware support, or if=20
the reason it wasn't useful was simply that most people don't have ARMs.

>Completely pointless unless you're doing it for fun or longterm
>research. Much better to put the effort into a good translation system
>to make good use of plain ol'vendor parts that will be twice as fast and
>half the price by the time you have it done. Don't fight Moore's Law.
>

I never said anything like that. I was refering to replacing your ASICs.

However, now that you brought it up, making a hardware (FPGA)=20
implementation of Smalltalk would indeed be fun (it looks like Jercel is=20
doing that) and it *might* make sense in some settings. Why do you think=20
Xilinx and Altera spend millions to develop their softcores (MicroBlaze=99=
=20
and Nios respectively) when obviously their performance can't reach that=20
of a substantially cheaper of-the-shelf part? Softcores make sense for=20
example for an embedded device where board space is at a premium and=20
there already is a substantiel need for custom logic.

Of course for a custom general purpose system there really is no way to=20
beat the performance of a $100 x86 chip.

>>Again, what special hardware support is needed? Object memory like on=20
>>the Newton?
>> =20
>>
>Bandwidth. Big onchip cache (128Mb would be nice :-) More bandwidth.
>Very fast interrupt handling (ARM does this part well).
> =20
>

What special hardware support did the _Interval_Smalltalk_ require was=20
what I meant. The StrongARM doesn't exactly have bandwidth nor big=20
on-chip caches and the MediaPad's custom (external) ASIC clearly didn't=20
implement a big cache.

For utmost bandwidth buy a P4 and fit it with 533 Mhz Rambus memory, but=20
then we're obviously out of the embedded space. StrongARM is probably a=20
bad choice anyway if you're seriously concerned about bandwidth.

/Tommy

[Tim Rowledge]

Tommy Thorn <***@meko.dk> is claimed by the authorities to have written:

> The ARM is pretty big in the embedded space. Did the ASIC provide
> functionality crucial for the native implementation of Smalltalk on
> StrongARM?
Well, yes - it provided the interface to memory and the LCD panel etc
since there were no commercial support chips at the time the h/w was
designed. These days one would probably just buy a standard part or
maybe even go with the SA1110 instead, which has most of it onchip.
>
> Not that I'm suggesting it, but FPGAs have progressed significantly in
> recent years. Yesterdays ASICs might be reimplementable with todays
> FPGAs (at a considerbly lower NRE cost).
If you were thinking of some magical hardware interpreter, forget it.
Completely pointless unless you're doing it for fun or longterm
research. Much better to put the effort into a good translation system
to make good use of plain ol'vendor parts that will be twice as fast and
half the price by the time you have it done. Don't fight Moore's Law.

> Again, what special hardware support is needed? Object memory like on
> the Newton?
Bandwidth. Big onchip cache (128Mb would be nice :-) More bandwidth.
Very fast interrupt handling (ARM does this part well).

tim

--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: SOD: Scribble On Disk

[Alan Kay]

Thanks Craig --

I really feel there will be an opportunity not too far in the future
when a lot of this great technology will make a big difference, and
will be very worthwhile to revisit....

Cheers,

Alan

------

At 4:50 PM -0700 10/3/02, Craig Latta wrote:
> Daniel writes:
>
>> And of course, this wonderful code is buried somewhere to never be
>> used again.
>
>short answer: It's not as bad as that.
>
>long answer:
>
> I'm sure the following is in the Google archives somewhere, but
>I'm too lazy to look it up... anyone please feel free to correct me.
>
> I was on the Interval Smalltalk team. Our system was part of a
>local media network system (homes, cars, etc.) which used a novel
>networking protocol ("MediaWire") that was cheap (ran over phone wire),
>synchronous, could support variable bitrates, and was, for the time,
>fast (100Mb). We worked on the "MediaPad", a sort of glorified remote
>control, a letter-sized touchscreen device with which you could control
>all the connected devices, make new composite devices, etc. It was
>similar in appearance to the failed crop of "web pads" which kept
>appearing later :). Tim and I showed off a couple of them at OOPSLA '99.
>I designed the device driver framework (a precursor to Flow).
>
> At the end of the project, we got permission to release all the
>non-MediaWire-specific software (pretty much the whole virtual machine,
>and most of the object memory). The catch is that only two of us had
>working MediaPad-building environments at the end (the end came
>suddenly). A different two of us (Tim and myself) had working MediaPads.
>Unfortunately, we've never been motivated enough collectively to get all
>the bits and hardware back together. Doing so would be some non-trivial
>amount of work, and we've all been busy with other things since. I
>actually have been releasing parts of the object memory over time,
>starting with the exception-handling framework I wrote (when Squeak
>didn't have one), then moving on to the device stuff. It's generally
>slow going though, because writing and performing music always gets more
>of my time.
>
> I expect the complete system would take a non-trivial amount of
>rework to retarget to different hardware. The MediaPad was always a
>home-grown prototype (based on the StrongARM 1100, and custom ASICs, at
>no small cost). The native code generator wouldn't be immediately useful
>to all Squeakers, for example. Some of the ARM development tools we used
>are not open-source. Another problem not to be underestimated is that
>both Tim and I have so far been too paranoid to attempt rewriting either
>of the MediaPad ROMs, for fear of the population of known demo-able
>MediaPads dropping by half. :) Also, the system got basic testing, but
>the project died before we could really pound it in actual homes.
>
> Anyway, the software is not closed as far as I know, but it's
>not in a state where it can meaningfully be distributed as a single
>coherent system. I think it's fair to say that most of us wouldn't feel
>right distributing something that people can't just fire up and use
>(leftover pride I suppose :). That mostly explains why the occasional
>"why doesn't the Interval Smalltalk system get released?" query is met
>with relative silence.
>
> I've always wanted to eventually get the whole thing released,
>though, and I plan to keep at it. I think a proper revival of the
>project would be a lot of fun and still very useful, too, but we'd have
>to solve the hardware environment problem first. I'm game. :)
>
> John writes:
>
>> The Interval project was a special case. They were building their
>> own custom hardware, so they HAD to write their own device drivers...
>
> Well, that was just the MediaPad and assorted networking glue
>(standalone clocks, hubs, etc.); the situation was a little more...
>interesting. Part of the plan was to collaborate with the major consumer
>electronics firms to establish MediaWire as a common interconnection
>technology (e.g., you'd find MediaWire ports on next-generation TVs, CD
>players, etc.). We were going for all the traditional closed-spec
>devices in addition to our own stuff, by being part of the specs. It was
>Big. :) The Japanese financial crisis in 1998 took most of the wind out
>of those sails (the biggest potential collaborators were deeply
>affected). I tend to agree with Tim that Mr. Bill finished it off.
>
>> ...and they had a large team of both hardware and software engineers.
>
> It wasn't that large, really. The comparison we liked to bat around was
>the fifteen of us versus the thousand people developing WinCE. :)
>
> Tim writes:
>
>> I'm pretty much convinced [implementing everything, including device
>> drivers, in Smalltalk] isn't really worth it. At least, not unless
>> one can fairly seriously rejig things to provide useful OS type
>> facilities like protection of one application's memory from another,
>> all that stuff.
>
> Indeed... and I thought we were well on our way. :) I thought having
>everything written in Squeak was fantastic. It made debugging things
>easier, and it was much simpler to explain the overall system
>architecture to newcomers. It afforded a great deal of useful technical
>control. And it was just more fun, which does have value.
>
> At the same time, I'm all for creating the illusion of object memory
>anywhere it's useful, including OSKit and the "commodity" OS platforms.
>The trick is where to stop... in Interval's case, there were very good
>technical and business reasons for "going deep". Most of the time, as a
>single individual with a limited lifespan, I'm content to get on with
>higher priorities as long as the supporting stuff isn't too distracting.
>
>> I agree with Dan's old aphorism about the OS but I think a better
>> interpretation of it is that nothing in the OS should be unreachable
>> from your language - not that there shouldn't be the OS there at all.
>
> To a large degree I view The Aphorism as a statement of that time, when
>the technology wasn't as pervasive and things were more open to change.
>And somewhere there should be a footnote: "Things get weird when
>billionaires are nearby." :)
>
>
>-C
>
>--
>Craig Latta
>improvisational musical informaticist
>***@netjam.org
>www.netjam.org/resume
>Smalltalkers do: [:it | All with: Class, (And love: it)]


--

[Tommy Thorn]

Craig,

thanks a lot for the most interesting account

> I expect the complete system would take a non-trivial amount of
>rework to retarget to different hardware. The MediaPad was always a
>home-grown prototype (based on the StrongARM 1100, and custom ASICs, at
>no small cost). The native code generator wouldn't be immediately useful
>to all Squeakers, for example.
>

The ARM is pretty big in the embedded space. Did the ASIC provide
functionality crucial for the native implementation of Smalltalk on
StrongARM?

Not that I'm suggesting it, but FPGAs have progressed significantly in
recent years. Yesterdays ASICs might be reimplementable with todays
FPGAs (at a considerbly lower NRE cost).

> I've always wanted to eventually get the whole thing released,
>though, and I plan to keep at it. I think a proper revival of the
>project would be a lot of fun and still very useful, too, but we'd have
>to solve the hardware environment problem first. I'm game. :)
>

Again, what special hardware support is needed? Object memory like on
the Newton?

All the best,

Tommy

[Alan Kay]

Thanks Craig --

I really feel there will be an opportunity not too far in the future
when a lot of this great technology will make a big difference, and
will be very worthwhile to revisit....

Cheers,

Alan

------

At 4:50 PM -0700 10/3/02, Craig Latta wrote:
> Daniel writes:
>
>> And of course, this wonderful code is buried somewhere to never be
>> used again.
>
>short answer: It's not as bad as that.
>
>long answer:
>
> I'm sure the following is in the Google archives somewhere, but
>I'm too lazy to look it up... anyone please feel free to correct me.
>
> I was on the Interval Smalltalk team. Our system was part of a
>local media network system (homes, cars, etc.) which used a novel
>networking protocol ("MediaWire") that was cheap (ran over phone wire),
>synchronous, could support variable bitrates, and was, for the time,
>fast (100Mb). We worked on the "MediaPad", a sort of glorified remote
>control, a letter-sized touchscreen device with which you could control
>all the connected devices, make new composite devices, etc. It was
>similar in appearance to the failed crop of "web pads" which kept
>appearing later :). Tim and I showed off a couple of them at OOPSLA '99.
>I designed the device driver framework (a precursor to Flow).
>
> At the end of the project, we got permission to release all the
>non-MediaWire-specific software (pretty much the whole virtual machine,
>and most of the object memory). The catch is that only two of us had
>working MediaPad-building environments at the end (the end came
>suddenly). A different two of us (Tim and myself) had working MediaPads.
>Unfortunately, we've never been motivated enough collectively to get all
>the bits and hardware back together. Doing so would be some non-trivial
>amount of work, and we've all been busy with other things since. I
>actually have been releasing parts of the object memory over time,
>starting with the exception-handling framework I wrote (when Squeak
>didn't have one), then moving on to the device stuff. It's generally
>slow going though, because writing and performing music always gets more
>of my time.
>
> I expect the complete system would take a non-trivial amount of
>rework to retarget to different hardware. The MediaPad was always a
>home-grown prototype (based on the StrongARM 1100, and custom ASICs, at
>no small cost). The native code generator wouldn't be immediately useful
>to all Squeakers, for example. Some of the ARM development tools we used
>are not open-source. Another problem not to be underestimated is that
>both Tim and I have so far been too paranoid to attempt rewriting either
>of the MediaPad ROMs, for fear of the population of known demo-able
>MediaPads dropping by half. :) Also, the system got basic testing, but
>the project died before we could really pound it in actual homes.
>
> Anyway, the software is not closed as far as I know, but it's
>not in a state where it can meaningfully be distributed as a single
>coherent system. I think it's fair to say that most of us wouldn't feel
>right distributing something that people can't just fire up and use
>(leftover pride I suppose :). That mostly explains why the occasional
>"why doesn't the Interval Smalltalk system get released?" query is met
>with relative silence.
>
> I've always wanted to eventually get the whole thing released,
>though, and I plan to keep at it. I think a proper revival of the
>project would be a lot of fun and still very useful, too, but we'd have
>to solve the hardware environment problem first. I'm game. :)
>
> John writes:
>
>> The Interval project was a special case. They were building their
>> own custom hardware, so they HAD to write their own device drivers...
>
> Well, that was just the MediaPad and assorted networking glue
>(standalone clocks, hubs, etc.); the situation was a little more...
>interesting. Part of the plan was to collaborate with the major consumer
>electronics firms to establish MediaWire as a common interconnection
>technology (e.g., you'd find MediaWire ports on next-generation TVs, CD
>players, etc.). We were going for all the traditional closed-spec
>devices in addition to our own stuff, by being part of the specs. It was
>Big.:) The Japanese financial crisis in 1998 took most of the wind out
>of those sails (the biggest potential collaborators were deeply
>affected). I tend to agree with Tim that Mr. Bill finished it off.
>
>> ...and they had a large team of both hardware and software engineers.
>
> It wasn't that large, really. The comparison we liked to bat around was
>the fifteen of us versus the thousand people developing WinCE. :)
>
> Tim writes:
>
>> I'm pretty much convinced [implementing everything, including device
>> drivers, in Smalltalk] isn't really worth it. At least, not unless
>> one can fairly seriously rejig things to provide useful OS type
>> facilities like protection of one application's memory from another,
>> all that stuff.
>
> Indeed... and I thought we were well on our way. :) I thought having
>everything written in Squeak was fantastic. It made debugging things
>easier, and it was much simpler to explain the overall system
>architecture to newcomers. It afforded a great deal of useful technical
>control. And it was just more fun, which does have value.
>
> At the same time, I'm all for creating the illusion of object memory
>anywhere it's useful, including OSKit and the "commodity" OS platforms.
>The trick is where to stop... in Interval's case, there were very good
>technical and business reasons for "going deep". Most of the time, as a
>single individual with a limited lifespan, I'm content to get on with
>higher priorities as long as the supporting stuff isn't too distracting.
>
>> I agree with Dan's old aphorism about the OS but I think a better
>> interpretation of it is that nothing in the OS should be unreachable
>> from your language - not that there shouldn't be the OS there at all.
>
> To a large degree I view The Aphorism as a statement of that time, when
>the technology wasn't as pervasive and things were more open to change.
>And somewhere there should be a footnote: "Things get weird when
>billionaires are nearby." :)
>
>
>-C
>
>--
>Craig Latta
>improvisational musical informaticist
>***@netjam.org
>www.netjam.org/resume
>Smalltalkers do: [:it | All with: Class, (And love: it)]


--

[Tom Rushworth]

On Wed, Oct 02, 2002 at 11:24:53PM -0500, Daniel Joyce wrote:
>
> >
> > At Interval Research we made a realtime OS out of Squeak. Seemed
> > promising, which of course is why it was canned in favour of WinCE. A
> > just about readable copy of my OOPSLA 99 paper on the system is at
> > http://sumeru.stanford.edu/tim/pooters/RTOSinSmalltalk.html
> >
> > tim

[snip]

> Will we ever see the light of this stuff from Interval? Could we buy it?
> I mean, the users of Blender bought the source code out, and open
> sourced it. Could we do the same? Is there a price?
>
> I'll put $250 where my mouth is on this issue.

So will I.
>
> -Daniel
>
>

--
Tom Rushworth

[Craig Latta]

Daniel writes:

> And of course, this wonderful code is buried somewhere to never be
> used again.

short answer: It's not as bad as that.

long answer:

I'm sure the following is in the Google archives somewhere, but
I'm too lazy to look it up... anyone please feel free to correct me.

I was on the Interval Smalltalk team. Our system was part of a
local media network system (homes, cars, etc.) which used a novel
networking protocol ("MediaWire") that was cheap (ran over phone wire),
synchronous, could support variable bitrates, and was, for the time,
fast (100Mb). We worked on the "MediaPad", a sort of glorified remote
control, a letter-sized touchscreen device with which you could control
all the connected devices, make new composite devices, etc. It was
similar in appearance to the failed crop of "web pads" which kept
appearing later :). Tim and I showed off a couple of them at OOPSLA '99.
I designed the device driver framework (a precursor to Flow).

At the end of the project, we got permission to release all the
non-MediaWire-specific software (pretty much the whole virtual machine,
and most of the object memory). The catch is that only two of us had
working MediaPad-building environments at the end (the end came
suddenly). A different two of us (Tim and myself) had working MediaPads.
Unfortunately, we've never been motivated enough collectively to get all
the bits and hardware back together. Doing so would be some non-trivial
amount of work, and we've all been busy with other things since. I
actually have been releasing parts of the object memory over time,
starting with the exception-handling framework I wrote (when Squeak
didn't have one), then moving on to the device stuff. It's generally
slow going though, because writing and performing music always gets more
of my time.

I expect the complete system would take a non-trivial amount of
rework to retarget to different hardware. The MediaPad was always a
home-grown prototype (based on the StrongARM 1100, and custom ASICs, at
no small cost). The native code generator wouldn't be immediately useful
to all Squeakers, for example. Some of the ARM development tools we used
are not open-source. Another problem not to be underestimated is that
both Tim and I have so far been too paranoid to attempt rewriting either
of the MediaPad ROMs, for fear of the population of known demo-able
MediaPads dropping by half. :) Also, the system got basic testing, but
the project died before we could really pound it in actual homes.

Anyway, the software is not closed as far as I know, but it's
not in a state where it can meaningfully be distributed as a single
coherent system. I think it's fair to say that most of us wouldn't feel
right distributing something that people can't just fire up and use
(leftover pride I suppose :). That mostly explains why the occasional
"why doesn't the Interval Smalltalk system get released?" query is met
with relative silence.

I've always wanted to eventually get the whole thing released,
though, and I plan to keep at it. I think a proper revival of the
project would be a lot of fun and still very useful, too, but we'd have
to solve the hardware environment problem first. I'm game. :)

John writes:

> The Interval project was a special case. They were building their
> own custom hardware, so they HAD to write their own device drivers...

Well, that was just the MediaPad and assorted networking glue
(standalone clocks, hubs, etc.); the situation was a little more...
interesting. Part of the plan was to collaborate with the major consumer
electronics firms to establish MediaWire as a common interconnection
technology (e.g., you'd find MediaWire ports on next-generation TVs, CD
players, etc.). We were going for all the traditional closed-spec
devices in addition to our own stuff, by being part of the specs. It was
Big.:) The Japanese financial crisis in 1998 took most of the wind out
of those sails (the biggest potential collaborators were deeply
affected). I tend to agree with Tim that Mr. Bill finished it off.

> ...and they had a large team of both hardware and software engineers.

It wasn't that large, really. The comparison we liked to bat around was
the fifteen of us versus the thousand people developing WinCE. :)

Tim writes:

> I'm pretty much convinced [implementing everything, including device
> drivers, in Smalltalk] isn't really worth it. At least, not unless
> one can fairly seriously rejig things to provide useful OS type
> facilities like protection of one application's memory from another,
> all that stuff.

Indeed... and I thought we were well on our way. :) I thought having
everything written in Squeak was fantastic. It made debugging things
easier, and it was much simpler to explain the overall system
architecture to newcomers. It afforded a great deal of useful technical
control. And it was just more fun, which does have value.

At the same time, I'm all for creating the illusion of object memory
anywhere it's useful, including OSKit and the "commodity" OS platforms.
The trick is where to stop... in Interval's case, there were very good
technical and business reasons for "going deep". Most of the time, as a
single individual with a limited lifespan, I'm content to get on with
higher priorities as long as the supporting stuff isn't too distracting.

> I agree with Dan's old aphorism about the OS but I think a better
> interpretation of it is that nothing in the OS should be unreachable
> from your language - not that there shouldn't be the OS there at all.

To a large degree I view The Aphorism as a statement of that time, when
the technology wasn't as pervasive and things were more open to change.
And somewhere there should be a footnote: "Things get weird when
billionaires are nearby." :)


-C

--
Craig Latta
improvisational musical informaticist
***@netjam.org
www.netjam.org/resume
Smalltalkers do: [:it | All with: Class, (And love: it)]

[Tom Rushworth]

On Wed, Oct 02, 2002 at 11:24:53PM -0500, Daniel Joyce wrote:
>
> >
> > At Interval Research we made a realtime OS out of Squeak. Seemed
> > promising, which of course is why it was canned in favour of WinCE. A
> > just about readable copy of my OOPSLA 99 paper on the system is at
> > http://sumeru.stanford.edu/tim/pooters/RTOSinSmalltalk.html
> >
> > tim

[snip]

> Will we ever see the light of this stuff from Interval? Could we buy it?
> I mean, the users of Blender bought the source code out, and open
> sourced it. Could we do the same? Is there a price?
>
> I'll put $250 where my mouth is on this issue.

So will I.
>
> -Daniel
>
>

--
Tom Rushworth

[JohnMaloney at earthlink.net ()]

Re:
>And of course, this wonderful code is buried somewhere to never be used
>again. The wonders of propietary closed source software. Interval has
>donated some things, but if they didn't want to use a RTOS Squeak, what
>makes them think someone else ever will? ( Why hold on to dead project
>code? No one is gonna buy it! Set it free! ).

One of the achievements of the Interval SqueakOS was to allow device
drivers to be written in Squeak. That's a pretty fancy trick, and they
pulled it off.

However, the current Squeak can and has been used as it's own operating
system with device drivers written in a combination of C and assembly
language. It has been done at least twice, once at Disney for a StrongARM
developer's board and once at Mitsubishi for an experimental processor
called the M32R/D. In both cases the development effort took about six
weeks, most it spent writing device drivers for the mouse, display, clocks,
and the Flash memory file system. The M32R/D Squeak even had a sound driver,
and Alan used it to give a demo of an early version of the EToy system,
to the great amazement of the Mitsubishi executives.

So, it's really quite easy to get Squeak running on bare hardware.

But...

Once you've done it you realize that there is a lot of hardware out there,
like wireless cards, cameras, drives, etc. Hardware specs for these
devices are often unavailable to developers because the vendors typically
supply their own device drivers for the standard OS's. So even if you
have the time to write your own device drivers, you may lack the
necessary documentation.

My conclusion is that, even if you don't want an OS for any other reason,
it has definite value as a standard for device drivers. Assuming you can get
the OS to give Squeak most of the processor cycles, the main advantage
of ditching the OS is to get back some memory. On handheld devices,
that can be significant, but in most cases I think it's probabably more
practical to co-exist with an OS so you can use it's device drivers.

The Interval project was a special case. They were building their own
custom hardware, so they HAD to write their own device drivers, and
they had a large team of both hardware and software engineers.

-- John

[Tim Rowledge]

J
> One of the achievements of the Interval SqueakOS was to allow device
> drivers to be written in Squeak. That's a pretty fancy trick, and they
> pulled it off.
Just barely, and I'm pretty much convinced it isn't really worth it. At
least, not unless one can fairly seriously rejig things to provide
useful OS type facilities like protection of one application's mmory
from another, all that stuff.

>
> So, it's really quite easy to get Squeak running on bare hardware.
>
> But...
>
> Once you've done it you realize that there is a lot of hardware out there,
> like wireless cards, cameras, drives, etc. Hardware specs for these
> devices are often unavailable to developers because the vendors typically
> supply their own device drivers for the standard OS's. So even if you
> have the time to write your own device drivers, you may lack the
> necessary documentation.
Exactly. Not to mention that writing a tcp/ip stack is a bit of a
labour. Why not use one that has already been written and tested? That's
why I tend to think that using the OSKit is a good idea. It allows use
of linux device drivers and so on. Big savings in effort. SqueakNOS is
an excellent project using this approach.

I agree with Dan's old aphorism about the OS but I think a better
interpretation of it is that nothing in the OS should be unreachable
from your language - not that there shouldn't be the OS there at all.


--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: PHP: Put Hackers into Privileged mode

[Tim Rowledge]

J
> One of the achievements of the Interval SqueakOS was to allow device
> drivers to be written in Squeak. That's a pretty fancy trick, and they
> pulled it off.
Just barely, and I'm pretty much convinced it isn't really worth it. At
least, not unless one can fairly seriously rejig things to provide
useful OS type facilities like protection of one application's mmory
from another, all that stuff.

>
> So, it's really quite easy to get Squeak running on bare hardware.
>
> But...
>
> Once you've done it you realize that there is a lot of hardware out there,
> like wireless cards, cameras, drives, etc. Hardware specs for these
> devices are often unavailable to developers because the vendors typically
> supply their own device drivers for the standard OS's. So even if you
> have the time to write your own device drivers, you may lack the
> necessary documentation.
Exactly. Not to mention that writing a tcp/ip stack is a bit of a
labour. Why not use one that has already been written and tested? That's
why I tend to think that using the OSKit is a good idea. It allows use
of linux device drivers and so on. Big savings in effort. SqueakNOS is
an excellent project using this approach.

I agree with Dan's old aphorism about the OS but I think a better
interpretation of it is that nothing in the OS should be unreachable
from your language - not that there shouldn't be the OS there at all.


--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: PHP: Put Hackers into Privileged mode

[Daniel Joyce]

>
> At Interval Research we made a realtime OS out of Squeak. Seemed
> promising, which of course is why it was canned in favour of WinCE. A
> just about readable copy of my OOPSLA 99 paper on the system is at
> http://sumeru.stanford.edu/tim/pooters/RTOSinSmalltalk.html
>
> tim

And of course, this wonderful code is buried somewhere to never be used
again. The wonders of propietary closed source software. Interval has
donated some things, but if they didn't want to use a RTOS Squeak, what
makes them think someone else ever will? ( Why hold on to dead project
code? No one is gonna buy it! Set it free! ).

RTOS Squeak now moulders on a musty tape somewhere with NEWS and other
innovative software that people could learn from... Heck, they managed
to talk SUN into releasing SELF, and SUN is still around... <:)

This is something the squeak community could really use ( along with a
robust clean widget set in the image, last time I looked, Prefab is not
included, and the morphic widgets are all half-implemented or
excessively hairy). This would go a long ways to help making Squeak
very very very very useful for more than just one-off demos and
presentation eye-candy. I play with Squeak alot, but I bang my head
against it sometime.

Will we ever see the light of this stuff from Interval? Could we buy it?
I mean, the users of Blender bought the source code out, and open
sourced it. Could we do the same? Is there a price?

I'll put $250 where my mouth is on this issue.

-Daniel

[squeak-dev at lists.squeakfoundation.org ()]

Re:
>And of course, this wonderful code is buried somewhere to never be used
>again. The wonders of propietary closed source software. Interval has
>donated some things, but if they didn't want to use a RTOS Squeak, what
>makes them think someone else ever will? ( Why hold on to dead project
>code? No one is gonna buy it! Set it free! ).

One of the achievements of the Interval SqueakOS was to allow device
drivers to be written in Squeak. That's a pretty fancy trick, and they
pulled it off.

However, the current Squeak can and has been used as it's own operating
system with device drivers written in a combination of C and assembly
language. It has been done at least twice, once at Disney for a StrongARM
developer's board and once at Mitsubishi for an experimental processor
called the M32R/D. In both cases the development effort took about six
weeks, most it spent writing device drivers for the mouse, display, clocks,
and the Flash memory file system. The M32R/D Squeak even had a sound driver,
and Alan used it to give a demo of an early version of the EToy system,
to the great amazement of the Mitsubishi executives.

So, it's really quite easy to get Squeak running on bare hardware.

But...

Once you've done it you realize that there is a lot of hardware out there,
like wireless cards, cameras, drives, etc. Hardware specs for these
devices are often unavailable to developers because the vendors typically
supply their own device drivers for the standard OS's. So even if you
have the time to write your own device drivers, you may lack the
necessary documentation.

My conclusion is that, even if you don't want an OS for any other reason,
it has definite value as a standard for device drivers. Assuming you can get
the OS to give Squeak most of the processor cycles, the main advantage
of ditching the OS is to get back some memory. On handheld devices,
that can be significant, but in most cases I think it's probabably more
practical to co-exist with an OS so you can use it's device drivers.

The Interval project was a special case. They were building their own
custom hardware, so they HAD to write their own device drivers, and
they had a large team of both hardware and software engineers.

-- John

[Jecel Assumpcao Jr]

On Wednesday 02 October 2002 14:06, Derek Brans wrote:
> How difficult would it be to turn Squeak into an OS? Has there been
> any discussion / papers about this that someone can point me to?

Check out http://sourceforge.net/projects/squeaknos/ and
http://mathmorphs.swiki.net/9

Did you know that before Digitalk introduced Methods (later Smalltalk/V)
for PCs running DOS in 1985, Smalltalk was always implemented on the
raw hardware?

"Operating System: An operating system is a collection of things that
don't fit into a language. There shouldn't be one."
Daniel H H Ingalls in "Design Principals Behind Smalltalk", August
1981 issue of Byte Magazine, pages 286 to 298

-- Jecel

[Tim Rowledge]

Derek Brans <***@phasecraft.com> is claimed by the authorities to have written:

> How difficult would it be to turn Squeak into an OS? Has there been any
> discussion / papers about this that someone can point me to?
At Interval Research we made a realtime OS out of Squeak. Seemed
promising, which of course is why it was canned in favour of WinCE. A
just about readable copy of my OOPSLA 99 paper on the system is at
http://sumeru.stanford.edu/tim/pooters/RTOSinSmalltalk.html

tim
--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Computer Science: solving today's problems tomorrow.

[John M McIntosh]

I recall at last year's OOPSLA Ian was showing off a squeak image that
he was
booting via open firmware. Basically he was using open firmware on an
apple
powerbook to load a VM and an image instead of a commerical/opensource
Operating system.

I believe by use of some of the open firmware drives
(disk/network/video) he was able to manage
quite a bit without having to write drivers etc.

If someone really really needs this they should ask Ian for a copy I'd
guess.

Looked like a good way to do kioks software and not worry about OS
issues.

On Thursday, October 3, 2002, at 08:50 AM, ***@earthlink.net
wrote:

> Re:
>> And of course, this wonderful code is buried somewhere to never be
>> used
>> again. The wonders of propietary closed source software. Interval has
>> donated some things, but if they didn't want to use a RTOS Squeak,
>> what
>> makes them think someone else ever will? ( Why hold on to dead project
>> code? No one is gonna buy it! Set it free! ).
>
--
========================================================================
===
John M. McIntosh <***@smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

[Ian Piumarta]

On Thu, 3 Oct 2002, John M McIntosh wrote:

> I recall at last year's OOPSLA Ian was showing off a squeak image that
> he was booting via open firmware. Basically he was using open
> firmware on an apple powerbook to load a VM and an image instead of a
> commerical/opensource Operating system. I believe by use of some of
> the open firmware drives (disk/network/video) he was able to manage
> quite a bit without having to write drivers etc.

OF gives you very limited functionality: just enough disk i/o to boot a
kernel and just enough console/keyboard to ask the uer where to look for
that kernel. After that you're pretty much on your own for mapping memory
and doing anything other than text console and keyboard -- there's no
mouse, for example, or graphics driver. OF's only really contribution to
your running kerner is that it has laready probed the hardware and built
you a device tree describing what's there. Configuring, enabling and then
using the devices is clearly the responsibility of your kernel not OF.

For Squeak I had to write my own mouse driver, the image was compressed
and placed in its own segment of `VM kernel' (no sources/changes) and I
almost got enough of the colourmap initialised to display the screen
correctly (although console framebuffers have a hard time with the notion
of `transparency' ;). But anyone who was there will remember the video
projector not wanting to display anything coming out of the vga connector.

> If someone really really needs this they should ask Ian for a copy I'd
> guess. Looked like a good way to do kioks software and not worry
> about OS issues.

You can only not worry up to the point where OF hands control to your
`kernel'. From that point on you're expected to do pretty much
everything, starting with mapping yourself some real memory and deciding
how you're going to deal with (raw!) interrupts, etc...

Ian

[Luciano Notarfrancesco]

Hey Tim,

Tim wrote:
> Exactly. Not to mention that writing a tcp/ip stack
> is a bit of a labour. Why not use one that has
> already been written and tested? That's why I tend
> to think that using the OSKit is a good idea. It
> allows use of linux device drivers and so on.
> Big savings in effort. SqueakNOS is an excellent
> project using this approach.

Actually, we took exactly the opposite approach. Not
the OSKit or Linux approach. We've implemented all the
drivers in Squeak. We're handling interrupts (all of
them, except the clock IRQ) in Squeak, via a Semaphore
that is signaled in a generic IRQ handler in the VM.
We've implemented drivers for the serial port,
keyboard and PS/2 mouse. We have classes with names
like PIC8259 (the Programmable Interrupt Controller),
PCKeyboard, UART8250, UART16550, etc. This is crazy, I
know, it's a lot of fun. It is great to be able to
speak directly to the hardware objects from Squeak,
sending them messages and making it crash sometimes :)

It's funny that you mention the project of writing a
TCP/IP stack in Smalltalk from scratch. I've been
doing exactly that in my spare time, and it works, or
kind of (ARP, IP and UDP are working fine, and TCP is
almost there, but with no fany stuff like delayed
ACKs). We implemented SLIP over the UART8250 and were
able to ping SqueakNOS from a Linux box.

But please don't compare this homegrown OS to the
Interval SqueakOS. We're four or five persons (from
Argentina) working on our spare time, and the last
time we got together to do put some work on SqueakNOS
was like 6 o 8 months ago.

Cheers,
Luciano.-

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[Tim Rowledge]

Luciano Notarfrancesco <***@yahoo.com> is claimed by the authorities to have written:

> Actually, we took exactly the opposite approach. Not
> the OSKit or Linux approach.
Urk? Now I'm confused; so where did I see stuff about using the OSKit to
support Squeak? Ah the joys of sen.... err what was I saying?

> We've implemented all the
> drivers in Squeak. We're handling interrupts (all of
> them, except the clock IRQ) in Squeak, via a Semaphore
> that is signaled in a generic IRQ handler in the VM.
> We've implemented drivers for the serial port,
> keyboard and PS/2 mouse. We have classes with names
> like PIC8259 (the Programmable Interrupt Controller),
> PCKeyboard, UART8250, UART16550, etc. This is crazy, I
> know, it's a lot of fun. It is great to be able to
> speak directly to the hardware objects from Squeak,
> sending them messages and making it crash sometimes :)
You bloomin' heroes. I am aghast. I am stunned. I wrote a serial port
driver in the old Acorn port of BrouHaHa Smalltalk many years ago that
could handle 9600 baud ok, but you folks have really gone crazy.
>
> It's funny that you mention the project of writing a
> TCP/IP stack in Smalltalk from scratch. I've been
> doing exactly that in my spare time, and it works, or
> kind of (ARP, IP and UDP are working fine, and TCP is
> almost there, but with no fany stuff like delayed
> ACKs). We implemented SLIP over the UART8250 and were
> able to ping SqueakNOS from a Linux box.
Good grief. I mean, _good grief_. You're all certifiably, wonderfully,
insane. This is seriously neat stuff. Have you formed any ideas of how
much slower (or even faster?) your stack is than a 'normal' one?
>
> But please don't compare this homegrown OS to the
> Interval SqueakOS. We're four or five persons (from
> Argentina) working on our spare time, and the last
> time we got together to do put some work on SqueakNOS
> was like 6 o 8 months ago.
The Interval project only had half-a-dozen software people for the OS
and applications but we were working full time. Well, aside from sushi
breaks and parties etc. I wish there were some way of getting you
somemoney to help with this - you guys down there need it even more than
I do, and I'm having to sell a house to keep eating.

I wonder if it could be put on anything I have lying around. Hmm,
NetWinder, netBook, trio pad, old Acorn prototype......

tim

--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Bug? That's not a bug, that's a feature. -T. John Wendel

[Luciano Notarfrancesco]

Tim Rowledge wrote:

>Good grief. I mean, _good grief_. You're all certifiably, wonderfully,
>insane. This is seriously neat stuff. Have you formed any ideas of how
>much slower (or even faster?) your stack is than a 'normal' one?
>
We haven't done much testing yet. It seems to handle all right a ping
flood ('ping -f hostname') without loosing any packet.
Some years ago TCP/IP over 10 Mbits ethernet ran in processors 100 times
slower than what we have today, so I believe it will do all right at
that speed. But I doubt it will be able to handle 100 Mbits ethernet,
not to mention 1 GB.

>I wonder if it could be put on anything I have lying around. Hmm,
>NetWinder, netBook, trio pad, old Acorn prototype......
>
>
I'd be happy to try! And here Richie says he'd like to give it a try too :)

BTW, I just got my first ARM! Paul McDonough generously lend me an iPAQ
to play with. Two years ago I put linux and Squeak on that nifty thing,
but porting SqueakNOS to it is a whole different deal. I'll start
playing with it soon.

Luciano.-

[Eddie Cottongim]

With wireless ethernet common and cheap now, would it be possible for these
'glorified remote controls' to be dumb terminals?
They could have a lot less processor & ram, and more importantly, you
wouldn't have to worry about squeezing down Squeak or anything else into its
contraints; the software could be as big and fat as needed, running on a
host PC in the house somewhere. The handheld device would need enough
resources for a framebuffer, tcp/ip, and the remote GUI client, which
shouldn't be much at all by today's standards. I use VNC ( a remote desktop,
www.realvnc.org ) over 10 mpbs ethernet and its plenty fast for a 1024x768
screen in windows; a more custom implementation where you have a smaller
screen and tighter control over updates could be even better.

Just an idea,
Eddie

----- Original Message -----
From: "Luciano Notarfrancesco" <***@yahoo.com>
To: <squeak-***@lists.squeakfoundation.org>
Sent: Friday, October 04, 2002 1:21 PM
Subject: Re: SqueakOS


> Tim Rowledge wrote:
>
> >Good grief. I mean, _good grief_. You're all certifiably, wonderfully,
> >insane. This is seriously neat stuff. Have you formed any ideas of how
> >much slower (or even faster?) your stack is than a 'normal' one?
> >
> We haven't done much testing yet. It seems to handle all right a ping
> flood ('ping -f hostname') without loosing any packet.
> Some years ago TCP/IP over 10 Mbits ethernet ran in processors 100 times
> slower than what we have today, so I believe it will do all right at
> that speed. But I doubt it will be able to handle 100 Mbits ethernet,
> not to mention 1 GB.
>
> >I wonder if it could be put on anything I have lying around. Hmm,
> >NetWinder, netBook, trio pad, old Acorn prototype......
> >
> >
> I'd be happy to try! And here Richie says he'd like to give it a try too
:)
>
> BTW, I just got my first ARM! Paul McDonough generously lend me an iPAQ
> to play with. Two years ago I put linux and Squeak on that nifty thing,
> but porting SqueakNOS to it is a whole different deal. I'll start
> playing with it soon.
>
> Luciano.-
>
>

[Eddie Cottongim]

With wireless ethernet common and cheap now, would it be possible for these
'glorified remote controls' to be dumb terminals?
They could have a lot less processor & ram, and more importantly, you
wouldn't have to worry about squeezing down Squeak or anything else into its
contraints; the software could be as big and fat as needed, running on a
host PC in the house somewhere. The handheld device would need enough
resources for a framebuffer, tcp/ip, and the remote GUI client, which
shouldn't be much at all by today's standards. I use VNC ( a remote desktop,
www.realvnc.org ) over 10 mpbs ethernet and its plenty fast for a 1024x768
screen in windows; a more custom implementation where you have a smaller
screen and tighter control over updates could be even better.

Just an idea,
Eddie

----- Original Message -----
From: "Luciano Notarfrancesco" <***@yahoo.com>
To: <squeak-***@lists.squeakfoundation.org>
Sent: Friday, October 04, 2002 1:21 PM
Subject: Re: SqueakOS


> Tim Rowledge wrote:
>
> >Good grief. I mean, _good grief_. You're all certifiably, wonderfully,
> >insane. This is seriously neat stuff. Have you formed any ideas of how
> >much slower (or even faster?) your stack is than a 'normal' one?
> >
> We haven't done much testing yet. It seems to handle all right a ping
> flood ('ping -f hostname') without loosing any packet.
> Some years ago TCP/IP over 10 Mbits ethernet ran in processors 100 times
> slower than what we have today, so I believe it will do all right at
> that speed. But I doubt it will be able to handle 100 Mbits ethernet,
> not to mention 1 GB.
>
> >I wonder if it could be put on anything I have lying around. Hmm,
> >NetWinder, netBook, trio pad, old Acorn prototype......
> >
> >
> I'd be happy to try! And here Richie says he'd like to give it a try too
:)
>
> BTW, I just got my first ARM! Paul McDonough generously lend me an iPAQ
> to play with. Two years ago I put linux and Squeak on that nifty thing,
> but porting SqueakNOS to it is a whole different deal. I'll start
> playing with it soon.
>
> Luciano.-
>
>

[David T. Lewis]

On Fri, Oct 04, 2002 at 09:30:55AM -0700, Tim Rowledge wrote:
> Luciano Notarfrancesco <***@yahoo.com> is claimed by the authorities to have written:
>
> > We've implemented all the drivers in Squeak.

<snip>

> You bloomin' heroes. I am aghast. I am stunned. I wrote a serial port
> driver in the old Acorn port of BrouHaHa Smalltalk many years ago that
> could handle 9600 baud ok, but you folks have really gone crazy.

<snip>

> I wish there were some way of getting you
> somemoney to help with this - you guys down there need it even more than
> I do, and I'm having to sell a house to keep eating.

I believe that there are efforts under way to set up non-profit
organizations (Squeak Foundation, and a complimentary effort in Europe)
to support worthy Squeak projects. Assuming that an organization
is willing and legally able to accept substantial charitable donations
from philanthropic persons or organizations, and can supply such a
donation to a group of people working on a well defined project such
as the one in Argentina, then:

1) Set up a Swiki page to publicize projects which are available to
receive funding. Only a few projects should be identified (including
this one), and each project should have an explanation of its objectives,
its anticipated outcome, and an explanation of why the world could be a
better place when the project meets its objectives. Construct the page
in such a way that Google is likely to find it easily.

2) Spread the word. Somebody somewhere is waiting right now to donate
large sums of money to projects which will make the world a better
place, as long as the projects are aligned with the objectives or
interests of the potential donor.

3) When the donor emerges, work through the non-profit organization
(Squeak Foundation or whatever) to connect donor to the project,
provide routing of the funding to the project participants, and provide
accountability for the project activities and results back to the donor.

Luciano Notarfrancesco's project seems like a particularly good fit for
this. The project is (or can be) well defined. The project participants
are highly reputable and have a good chance of achieving the project
goals. A successful outcome would make the world a better place in a
number of interesting ways. And it's pretty cool, so it might be quite
appealing to certain kinds of donors.

Dave

[Luciano Notarfrancesco]

Tim Rowledge wrote:

>Good grief. I mean, _good grief_. You're all certifiably, wonderfully,
>insane. This is seriously neat stuff. Have you formed any ideas of how
>much slower (or even faster?) your stack is than a 'normal' one?
>
We haven't done much testing yet. It seems to handle all right a ping
flood ('ping -f hostname') without loosing any packet.
Some years ago TCP/IP over 10 Mbits ethernet ran in processors 100 times
slower than what we have today, so I believe it will do all right at
that speed. But I doubt it will be able to handle 100 Mbits ethernet,
not to mention 1 GB.

>I wonder if it could be put on anything I have lying around. Hmm,
>NetWinder, netBook, trio pad, old Acorn prototype......
>
>
I'd be happy to try! And here Richie says he'd like to give it a try too :)

BTW, I just got my first ARM! Paul McDonough generously lend me an iPAQ
to play with. Two years ago I put linux and Squeak on that nifty thing,
but porting SqueakNOS to it is a whole different deal. I'll start
playing with it soon.

Luciano.-

[David T. Lewis]

On Fri, Oct 04, 2002 at 09:30:55AM -0700, Tim Rowledge wrote:
> Luciano Notarfrancesco <***@yahoo.com> is claimed by the authorities to have written:
>
> > We've implemented all the drivers in Squeak.

<snip>

> You bloomin' heroes. I am aghast. I am stunned. I wrote a serial port
> driver in the old Acorn port of BrouHaHa Smalltalk many years ago that
> could handle 9600 baud ok, but you folks have really gone crazy.

<snip>

> I wish there were some way of getting you
> somemoney to help with this - you guys down there need it even more than
> I do, and I'm having to sell a house to keep eating.

I believe that there are efforts under way to set up non-profit
organizations (Squeak Foundation, and a complimentary effort in Europe)
to support worthy Squeak projects. Assuming that an organization
is willing and legally able to accept substantial charitable donations
from philanthropic persons or organizations, and can supply such a
donation to a group of people working on a well defined project such
as the one in Argentina, then:

1) Set up a Swiki page to publicize projects which are available to
receive funding. Only a few projects should be identified (including
this one), and each project should have an explanation of its objectives,
its anticipated outcome, and an explanation of why the world could be a
better place when the project meets its objectives. Construct the page
in such a way that Google is likely to find it easily.

2) Spread the word. Somebody somewhere is waiting right now to donate
large sums of money to projects which will make the world a better
place, as long as the projects are aligned with the objectives or
interests of the potential donor.

3) When the donor emerges, work through the non-profit organization
(Squeak Foundation or whatever) to connect donor to the project,
provide routing of the funding to the project participants, and provide
accountability for the project activities and results back to the donor.

Luciano Notarfrancesco's project seems like a particularly good fit for
this. The project is (or can be) well defined. The project participants
are highly reputable and have a good chance of achieving the project
goals. A successful outcome would make the world a better place in a
number of interesting ways. And it's pretty cool, so it might be quite
appealing to certain kinds of donors.

Dave

[Tim Rowledge]

Luciano Notarfrancesco <***@yahoo.com> is claimed by the authorities to have written:

> Actually, we took exactly the opposite approach. Not
> the OSKit or Linux approach.
Urk? Now I'm confused; so where did I see stuff about using the OSKit to
support Squeak? Ah the joys of sen.... err what was I saying?

> We've implemented all the
> drivers in Squeak. We're handling interrupts (all of
> them, except the clock IRQ) in Squeak, via a Semaphore
> that is signaled in a generic IRQ handler in the VM.
> We've implemented drivers for the serial port,
> keyboard and PS/2 mouse. We have classes with names
> like PIC8259 (the Programmable Interrupt Controller),
> PCKeyboard, UART8250, UART16550, etc. This is crazy, I
> know, it's a lot of fun. It is great to be able to
> speak directly to the hardware objects from Squeak,
> sending them messages and making it crash sometimes :)
You bloomin' heroes. I am aghast. I am stunned. I wrote a serial port
driver in the old Acorn port of BrouHaHa Smalltalk many years ago that
could handle 9600 baud ok, but you folks have really gone crazy.
>
> It's funny that you mention the project of writing a
> TCP/IP stack in Smalltalk from scratch. I've been
> doing exactly that in my spare time, and it works, or
> kind of (ARP, IP and UDP are working fine, and TCP is
> almost there, but with no fany stuff like delayed
> ACKs). We implemented SLIP over the UART8250 and were
> able to ping SqueakNOS from a Linux box.
Good grief. I mean, _good grief_. You're all certifiably, wonderfully,
insane. This is seriously neat stuff. Have you formed any ideas of how
much slower (or even faster?) your stack is than a 'normal' one?
>
> But please don't compare this homegrown OS to the
> Interval SqueakOS. We're four or five persons (from
> Argentina) working on our spare time, and the last
> time we got together to do put some work on SqueakNOS
> was like 6 o 8 months ago.
The Interval project only had half-a-dozen software people for the OS
and applications but we were working full time. Well, aside from sushi
breaks and parties etc. I wish there were some way of getting you
somemoney to help with this - you guys down there need it even more than
I do, and I'm having to sell a house to keep eating.

I wonder if it could be put on anything I have lying around. Hmm,
NetWinder, netBook, trio pad, old Acorn prototype......

tim

--
Tim Rowledge, ***@sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Bug? That's not a bug, that's a feature. -T. John Wendel

[Ian Piumarta]

On Thu, 3 Oct 2002, Tim Rowledge wrote:

> SUN tried at least acouple of times for java nad seem to have failed.
> SOAR was not very effective, Sword/32 failed, iAPX432 was a dog, etc
> etc.

I worked for a while on the REKURSIV project (a microcoded chipset for oo
languages) that did GC, binding, etc. -- the whole kaboodle -- in h/w.
(Even the microcode talked about objects.) It was hosted by a Sun3 (it
plugged directly into the backplane). It had its own language called
Lingo. While waiting for the hardware somebody implemented an interpreter
in C. By the time Lingo ran on the hardware, the interpreter (running on
a Sun3) was faster than Lingo running on the hardware.

The front-end was out-performing the mainframe.

To misquote (severely) Eliot Miranda: the portable (software) version was
faster than the platform-specific (hardware) version by virtue of its
portability.

That's enough irrelevance for one day... Over and out,

Ian

[Jecel Assumpcao Jr]

On Friday 04 October 2002 01:44, Ian Piumarta wrote:
> On Thu, 3 Oct 2002, Tim Rowledge wrote:
> > SUN tried at least acouple of times for java nad seem to have
> > failed. SOAR was not very effective, Sword/32 failed, iAPX432 was a
> > dog, etc etc.

I thought SOAR was a great success. It was just never cleaned up and
finished, as is typical of student projects.

What iAPX432? It has been eliminated from all processor histories I can
find. It seems that the 386 is now officially Intel's very first 32 bit
processor. Of course, for those of us who really miss the old 432 they
are doing IA64 ;-)

> I worked for a while on the REKURSIV project (a microcoded chipset
> for oo languages) that did GC, binding, etc. -- the whole kaboodle --
> in h/w. (Even the microcode talked about objects.) It was hosted by
> a Sun3 (it plugged directly into the backplane). It had its own
> language called Lingo. While waiting for the hardware somebody
> implemented an interpreter in C. By the time Lingo ran on the
> hardware, the interpreter (running on a Sun3) was faster than Lingo
> running on the hardware.

"It will not do to leave a live dragon out of your plans if you live
near one." J.R.R.TOLKIEN in The Hobbit

In this case the dragon is Moore's law being ridden by the main cpu
makers. Add to that the fact that software implementors can easily come
up with new and brilliant ideas to make things faster. Remember:
hardware can know the past but only the compiler can look into the
future!

That said, the Rekursiv was interesting and worth studying:

http://www.brouhaha.com/~eric/retrocomputing/rekursiv/

It did have against it some bad timing - the late 1980s were not very
kind to microcoded machines. It was an era when RISCs ruled the earth.
I think that this became clear to the Mushroom people (Ian, do you have
any comments about your participation in that one?):

http://www.wolczko.com/mushroom/index.html

To answer Tommy Thorn's question about what would be nice to have in a
Smalltalk cpu - the Mushroom used virtually addressed caches. That is,
you passed to the cache the pair {ObjectID, offset} and it would return
a word. You only have to convert the virtual address to a physical
memory address when you have a cache miss. So you can have all kinds of
indirections (object tables, for example) and it doesn't cost you too
much.

Another nice feature was that their generational garbage collector used
the cache exclusively in the youngest generation. So an object could be
created and later collected without causing a single external memory
reference if you got really lucky. As Tim explained the three most
important things are memory bandwidth, memory bandwidth and memory
bandwidth. This was a neat way to get it.

One thing that is annoying if you try to do a cpu to directly execute
bytecodes is that you have two sources of information in the
instructions: the bytecodes themselves and the literals. Most
processors have their literals mixed in the instruction stream, so as
you gobble it up they are right there when you need them.

Another problem with direct bytecode execution is that "you do as you
are told" and execute every single message send implied in the source
code. Modern compilation technology eliminates most sends (Self,
Hotspot Java and StrongTalk). In my smallest design (I am currently
working on three different architectures and have a fourth one that is
paused do to the lack of time) I have a one clock message send and two
clock return (assuming the cache hits), yet the Self compiler can often
get negative message send times! How can you compete with that? The
negative times were obtained by inlining a message send and then using
the new context information to optimize the inlined code so it was far
smaller and faster than the original.

About FPGAs - these didn't improve much through most of the 1990s but
now are advancing at an impressive pace. If you can do something
interesting with an FPGA you get to ride Moore's law with the big boys.
A FPGA with MicroBlaze, Nios or XSOC/xr16 is very competitive in both
price and performance with "normal" embedded processors (at least
between the smallest PICs and the StrongARM). And if you can tweak it
to run something like Smalltalk instead of yet another gcc driven MIPs
clone it really becomes worth it. My smallest machine costs $15 in
single quantities. I'll have some tiny benchmark numbers soon to put
that into the proper perspective.

BTW, what I wrote about hardware/software above supposes that the
hardware can't inline and optimize code, eliminate message sends, etc.
But I figured out how to do exactly that. Unfortunately this email is
too long already.... ;-)

-- Jecel

[Alan Kay]

Jecel --

Nice email. I won't enumerate any of the many PARC schemes for
dealing with fast execution of late bound languages (but consider the
"giant hash table" ...).
But I would like to mention the work of Phil Abrams and others
at Stanford and elsewhere in the late 60s and early 70s for on the
fly APL optimizations. They used algebraic manipulations of various
kinds in a limited HW window to create pretty optimal execution
streams (e.g. (A*B)[1 to 5] was manipulated into A[1 to 5] * B[1 to
5] before execution). There are some very nice generalizations of APL
ideas and algebras to polymorphic objects, many of which have not
been exploited as well as they could and should be.

Cheers,

Alan

-------

At 6:11 PM -0300 10/4/02, Jecel Assumpcao Jr wrote:
>On Friday 04 October 2002 01:44, Ian Piumarta wrote:
>> On Thu, 3 Oct 2002, Tim Rowledge wrote:
>> > SUN tried at least acouple of times for java nad seem to have
>> > failed. SOAR was not very effective, Sword/32 failed, iAPX432 was a
>> > dog, etc etc.
>
>I thought SOAR was a great success. It was just never cleaned up and
>finished, as is typical of student projects.
>
>What iAPX432? It has been eliminated from all processor histories I can
>find. It seems that the 386 is now officially Intel's very first 32 bit
>processor. Of course, for those of us who really miss the old 432 they
>are doing IA64 ;-)
>
>> I worked for a while on the REKURSIV project (a microcoded chipset
>> for oo languages) that did GC, binding, etc. -- the whole kaboodle --
>> in h/w. (Even the microcode talked about objects.) It was hosted by
>> a Sun3 (it plugged directly into the backplane). It had its own
>> language called Lingo. While waiting for the hardware somebody
>> implemented an interpreter in C. By the time Lingo ran on the
>> hardware, the interpreter (running on a Sun3) was faster than Lingo
>> running on the hardware.
>
>"It will not do to leave a live dragon out of your plans if you live
>near one." J.R.R.TOLKIEN in The Hobbit
>
>In this case the dragon is Moore's law being ridden by the main cpu
>makers. Add to that the fact that software implementors can easily come
>up with new and brilliant ideas to make things faster. Remember:
>hardware can know the past but only the compiler can look into the
>future!
>
>That said, the Rekursiv was interesting and worth studying:
>
> http://www.brouhaha.com/~eric/retrocomputing/rekursiv/
>
>It did have against it some bad timing - the late 1980s were not very
>kind to microcoded machines. It was an era when RISCs ruled the earth.
>I think that this became clear to the Mushroom people (Ian, do you have
>any comments about your participation in that one?):
>
> http://www.wolczko.com/mushroom/index.html
>
>To answer Tommy Thorn's question about what would be nice to have in a
>Smalltalk cpu - the Mushroom used virtually addressed caches. That is,
>you passed to the cache the pair {ObjectID, offset} and it would return
>a word. You only have to convert the virtual address to a physical
>memory address when you have a cache miss. So you can have all kinds of
>indirections (object tables, for example) and it doesn't cost you too
>much.
>
>Another nice feature was that their generational garbage collector used
>the cache exclusively in the youngest generation. So an object could be
>created and later collected without causing a single external memory
>reference if you got really lucky. As Tim explained the three most
>important things are memory bandwidth, memory bandwidth and memory
>bandwidth. This was a neat way to get it.
>
>One thing that is annoying if you try to do a cpu to directly execute
>bytecodes is that you have two sources of information in the
>instructions: the bytecodes themselves and the literals. Most
>processors have their literals mixed in the instruction stream, so as
>you gobble it up they are right there when you need them.
>
>Another problem with direct bytecode execution is that "you do as you
>are told" and execute every single message send implied in the source
>code. Modern compilation technology eliminates most sends (Self,
>Hotspot Java and StrongTalk). In my smallest design (I am currently
>working on three different architectures and have a fourth one that is
>paused do to the lack of time) I have a one clock message send and two
>clock return (assuming the cache hits), yet the Self compiler can often
>get negative message send times! How can you compete with that? The
>negative times were obtained by inlining a message send and then using
>the new context information to optimize the inlined code so it was far
>smaller and faster than the original.
>
>About FPGAs - these didn't improve much through most of the 1990s but
>now are advancing at an impressive pace. If you can do something
>interesting with an FPGA you get to ride Moore's law with the big boys.
>A FPGA with MicroBlaze, Nios or XSOC/xr16 is very competitive in both
>price and performance with "normal" embedded processors (at least
>between the smallest PICs and the StrongARM). And if you can tweak it
>to run something like Smalltalk instead of yet another gcc driven MIPs
>clone it really becomes worth it. My smallest machine costs $15 in
>single quantities. I'll have some tiny benchmark numbers soon to put
>that into the proper perspective.
>
>BTW, what I wrote about hardware/software above supposes that the
>hardware can't inline and optimize code, eliminate message sends, etc.
>But I figured out how to do exactly that. Unfortunately this email is
>too long already.... ;-)
>
>-- Jecel


--

[Jecel Assumpcao Jr]

On Friday 04 October 2002 19:58, Alan Kay wrote:
> Nice email. I won't enumerate any of the many PARC schemes for
> dealing with fast execution of late bound languages (but consider the
> "giant hash table" ...).

I can do far worse than that :-) My small machine has 8MB of SDRAM
since that was the cheapest memory chip around. But for this
application 2MB or so would probably have been enough. So I use a full
Selector x Class table for dispatch, even though it takes up 20 times
more memory than most reasonable approaches. No hash, but this 16 bit
machine is limited to 32K objects and only 4K selectors (too small for
Squeak, sorry).

> But I would like to mention the work of Phil Abrams and others
> at Stanford and elsewhere in the late 60s and early 70s for on the
> fly APL optimizations. They used algebraic manipulations of various
> kinds in a limited HW window to create pretty optimal execution
> streams (e.g. (A*B)[1 to 5] was manipulated into A[1 to 5] * B[1 to
> 5] before execution). There are some very nice generalizations of APL
> ideas and algebras to polymorphic objects, many of which have not
> been exploited as well as they could and should be.

This would be really great for high performance number crunching in
Smalltalk, as you have mentioned before. This paper looks very
interesting (you have to be an ACM member to read it, and I am not) and
has a reference to Phil's 1970 PhD thesis "An APL Machine":

http://portal.acm.org/citation.cfm?id=801914&dl=ACM&coll=portal

Given the authors, I imagine they concluded that trivial hardware and a
good compiler were the way to go...

I did get to see some of these kinds of optimizations in SISAL (Streams
and Iteration in a Single Assignment Language). It is sad to see so
many programmers doing Fortran style (now C plus assembly to get at MMX
or whatever their hardware's vector unit is called) coding for
multimedia and 3D.

-- Jecel

[Alan Grimes]

om

Before I switched my attention to AI, I was an OS devel who struggled to
figure out how to implement his ideas with free compilers just as I'm
struggeling with the gorry details of Morphic now. (don't worry, the
help I have recived from this list with morphic is already 1,000,000
times more than I ever got with ld.)

Basic problems between squeak and oshood are these:

-- managing raw hardware.
-- implementing security and resource protection.
-- seperating namespaces? (has this been solved and nobody told me)?

My solution to these is to implement a concept that I call the "sphere"
but that I must acknowlege has its roots sometime in the early 80's
known as a "System Sriented Operating System"

A system is like a heavy-weight dynamic class. I have an unrevised
version of my paper on my website. (the revised version got hosed with
my HD, and I cancled the project), I started to throw togeather a
"sphere" class this afternoon as a demo.

The sphere abstraction is the beginning of the system. I don't know
enough squeak to really discuss it in terms of squeak but I'll try
anyway. The basic idea is to make a squeak that can instantiate itself
within itself.

To begin, a sphere abstraction is applied to the entire VM. Then a
second abstraction is created that is logically "within" this outer
abstraction,
This second sphere is a protected sphere that is totally accessable by
the outer sphere but absolutly inaccessable to its peers. -- this is the
primary protection mechanism.

It communicates with its peers by publishing an interface to some
standard that are collected by the parent and offered on a market of
sorts, allowing spheres to find each other and make connections. It may
not be the most convienient way to operate but then the entire world
can't be squeak, all developed by the same family, this method of
negotiating interfaces is intended to make things run smoothly even when
they shouldn't. ;)

The operating system is implemented _AS_ a sphere. The most imortant
resources are the CPU and memory. The drivers for these contain whatever
is needed to controll the hardware.

I don't know wheather there are any commands for explicitly killing an
instance in squeak...

The primary motovation of sphere is managability, or example, I have no
idea why the "nobody" user on my leenooks system starts doing some mondo
expensive "find" task at midnight just about every night.... I only
nocied it because the system becomes badly bogged at that hour. In
sphere, it should be very easy to find out exactly what is happening
because all the connections can be tracked, and hopefully nothing will
be so poorly designed as to make the user feel as helpless as I do
around leenooks. =(

/me needs to go console himself by playing some DragonQuest 6 (snes ROM)
on his 486 with ZSNES under DOS.... =\

--
Sometime in 1996 God reached down from the heavens and created a game
called "Terranigma". ;)
http://users.rcn.com/alangrimes/

[Alan Grimes]

om

Before I switched my attention to AI, I was an OS devel who struggled to
figure out how to implement his ideas with free compilers just as I'm
struggeling with the gorry details of Morphic now. (don't worry, the
help I have recived from this list with morphic is already 1,000,000
times more than I ever got with ld.)

Basic problems between squeak and oshood are these:

-- managing raw hardware.
-- implementing security and resource protection.
-- seperating namespaces? (has this been solved and nobody told me)?

My solution to these is to implement a concept that I call the "sphere"
but that I must acknowlege has its roots sometime in the early 80's
known as a "System Sriented Operating System"

A system is like a heavy-weight dynamic class. I have an unrevised
version of my paper on my website. (the revised version got hosed with
my HD, and I cancled the project), I started to throw togeather a
"sphere" class this afternoon as a demo.

The sphere abstraction is the beginning of the system. I don't know
enough squeak to really discuss it in terms of squeak but I'll try
anyway. The basic idea is to make a squeak that can instantiate itself
within itself.

To begin, a sphere abstraction is applied to the entire VM. Then a
second abstraction is created that is logically "within" this outer
abstraction,
This second sphere is a protected sphere that is totally accessable by
the outer sphere but absolutly inaccessable to its peers. -- this is the
primary protection mechanism.

It communicates with its peers by publishing an interface to some
standard that are collected by the parent and offered on a market of
sorts, allowing spheres to find each other and make connections. It may
not be the most convienient way to operate but then the entire world
can't be squeak, all developed by the same family, this method of
negotiating interfaces is intended to make things run smoothly even when
they shouldn't. ;)

The operating system is implemented _AS_ a sphere. The most imortant
resources are the CPU and memory. The drivers for these contain whatever
is needed to controll the hardware.

I don't know wheather there are any commands for explicitly killing an
instance in squeak...

The primary motovation of sphere is managability, or example, I have no
idea why the "nobody" user on my leenooks system starts doing some mondo
expensive "find" task at midnight just about every night.... I only
nocied it because the system becomes badly bogged at that hour. In
sphere, it should be very easy to find out exactly what is happening
because all the connections can be tracked, and hopefully nothing will
be so poorly designed as to make the user feel as helpless as I do
around leenooks. =(

/me needs to go console himself by playing some DragonQuest 6 (snes ROM)
on his 486 with ZSNES under DOS.... =\

--
Sometime in 1996 God reached down from the heavens and created a game
called "Terranigma". ;)
http://users.rcn.com/alangrimes/

[Jecel Assumpcao Jr]

On Friday 04 October 2002 19:58, Alan Kay wrote:
> Nice email. I won't enumerate any of the many PARC schemes for
> dealing with fast execution of late bound languages (but consider the
> "giant hash table" ...).

I can do far worse than that :-) My small machine has 8MB of SDRAM
since that was the cheapest memory chip around. But for this
application 2MB or so would probably have been enough. So I use a full
Selector x Class table for dispatch, even though it takes up 20 times
more memory than most reasonable approaches. No hash, but this 16 bit
machine is limited to 32K objects and only 4K selectors (too small for
Squeak, sorry).

> But I would like to mention the work of Phil Abrams and others
> at Stanford and elsewhere in the late 60s and early 70s for on the
> fly APL optimizations. They used algebraic manipulations of various
> kinds in a limited HW window to create pretty optimal execution
> streams (e.g. (A*B)[1 to 5] was manipulated into A[1 to 5] * B[1 to
> 5] before execution). There are some very nice generalizations of APL
> ideas and algebras to polymorphic objects, many of which have not
> been exploited as well as they could and should be.

This would be really great for high performance number crunching in
Smalltalk, as you have mentioned before. This paper looks very
interesting (you have to be an ACM member to read it, and I am not) and
has a reference to Phil's 1970 PhD thesis "An APL Machine":

http://portal.acm.org/citation.cfm?id=801914&dl=ACM&coll=portal

Given the authors, I imagine they concluded that trivial hardware and a
good compiler were the way to go...

I did get to see some of these kinds of optimizations in SISAL (Streams
and Iteration in a Single Assignment Language). It is sad to see so
many programmers doing Fortran style (now C plus assembly to get at MMX
or whatever their hardware's vector unit is called) coding for
multimedia and 3D.

-- Jecel

[Alan Kay]

Jecel --

Nice email. I won't enumerate any of the many PARC schemes for
dealing with fast execution of late bound languages (but consider the
"giant hash table" ...).
But I would like to mention the work of Phil Abrams and others
at Stanford and elsewhere in the late 60s and early 70s for on the
fly APL optimizations. They used algebraic manipulations of various
kinds in a limited HW window to create pretty optimal execution
streams (e.g. (A*B)[1 to 5] was manipulated into A[1 to 5] * B[1 to
5] before execution). There are some very nice generalizations of APL
ideas and algebras to polymorphic objects, many of which have not
been exploited as well as they could and should be.

Cheers,

Alan

-------

At 6:11 PM -0300 10/4/02, Jecel Assumpcao Jr wrote:
>On Friday 04 October 2002 01:44, Ian Piumarta wrote:
>> On Thu, 3 Oct 2002, Tim Rowledge wrote:
>> > SUN tried at least acouple of times for java nad seem to have
>> > failed. SOAR was not very effective, Sword/32 failed, iAPX432 was a
>> > dog, etc etc.
>
>I thought SOAR was a great success. It was just never cleaned up and
>finished, as is typical of student projects.
>
>What iAPX432? It has been eliminated from all processor histories I can
>find. It seems that the 386 is now officially Intel's very first 32 bit
>processor. Of course, for those of us who really miss the old 432 they
>are doing IA64 ;-)
>
>> I worked for a while on the REKURSIV project (a microcoded chipset
>> for oo languages) that did GC, binding, etc. -- the whole kaboodle --
>> in h/w. (Even the microcode talked about objects.) It was hosted by
>> a Sun3 (it plugged directly into the backplane). It had its own
>> language called Lingo. While waiting for the hardware somebody
>> implemented an interpreter in C. By the time Lingo ran on the
>> hardware, the interpreter (running on a Sun3) was faster than Lingo
>> running on the hardware.
>
>"It will not do to leave a live dragon out of your plans if you live
>near one." J.R.R.TOLKIEN in The Hobbit
>
>In this case the dragon is Moore's law being ridden by the main cpu
>makers. Add to that the fact that software implementors can easily come
>up with new and brilliant ideas to make things faster. Remember:
>hardware can know the past but only the compiler can look into the
>future!
>
>That said, the Rekursiv was interesting and worth studying:
>
> http://www.brouhaha.com/~eric/retrocomputing/rekursiv/
>
>It did have against it some bad timing - the late 1980s were not very
>kind to microcoded machines. It was an era when RISCs ruled the earth.
>I think that this became clear to the Mushroom people (Ian, do you have
>any comments about your participation in that one?):
>
> http://www.wolczko.com/mushroom/index.html
>
>To answer Tommy Thorn's question about what would be nice to have in a
>Smalltalk cpu - the Mushroom used virtually addressed caches. That is,
>you passed to the cache the pair {ObjectID, offset} and it would return
>a word. You only have to convert the virtual address to a physical
>memory address when you have a cache miss. So you can have all kinds of
>indirections (object tables, for example) and it doesn't cost you too
>much.
>
>Another nice feature was that their generational garbage collector used
>the cache exclusively in the youngest generation. So an object could be
>created and later collected without causing a single external memory
>reference if you got really lucky. As Tim explained the three most
>important things are memory bandwidth, memory bandwidth and memory
>bandwidth. This was a neat way to get it.
>
>One thing that is annoying if you try to do a cpu to directly execute
>bytecodes is that you have two sources of information in the
>instructions: the bytecodes themselves and the literals. Most
>processors have their literals mixed in the instruction stream, so as
>you gobble it up they are right there when you need them.
>
>Another problem with direct bytecode execution is that "you do as you
>are told" and execute every single message send implied in the source
>code. Modern compilation technology eliminates most sends (Self,
>Hotspot Java and StrongTalk). In my smallest design (I am currently
>working on three different architectures and have a fourth one that is
>paused do to the lack of time) I have a one clock message send and two
>clock return (assuming the cache hits), yet the Self compiler can often
>get negative message send times! How can you compete with that? The
>negative times were obtained by inlining a message send and then using
>the new context information to optimize the inlined code so it was far
>smaller and faster than the original.
>
>About FPGAs - these didn't improve much through most of the 1990s but
>now are advancing at an impressive pace. If you can do something
>interesting with an FPGA you get to ride Moore's law with the big boys.
>A FPGA with MicroBlaze, Nios or XSOC/xr16 is very competitive in both
>price and performance with "normal" embedded processors (at least
>between the smallest PICs and the StrongARM). And if you can tweak it
>to run something like Smalltalk instead of yet another gcc driven MIPs
>clone it really becomes worth it. My smallest machine costs $15 in
>single quantities. I'll have some tiny benchmark numbers soon to put
>that into the proper perspective.
>
>BTW, what I wrote about hardware/software above supposes that the
>hardware can't inline and optimize code, eliminate message sends, etc.
>But I figured out how to do exactly that. Unfortunately this email is
>too long already.... ;-)
>
>-- Jecel


--

[Jecel Assumpcao Jr]

On Friday 04 October 2002 01:44, Ian Piumarta wrote:
> On Thu, 3 Oct 2002, Tim Rowledge wrote:
> > SUN tried at least acouple of times for java nad seem to have
> > failed. SOAR was not very effective, Sword/32 failed, iAPX432 was a
> > dog, etc etc.

I thought SOAR was a great success. It was just never cleaned up and
finished, as is typical of student projects.

What iAPX432? It has been eliminated from all processor histories I can
find. It seems that the 386 is now officially Intel's very first 32 bit
processor. Of course, for those of us who really miss the old 432 they
are doing IA64 ;-)

> I worked for a while on the REKURSIV project (a microcoded chipset
> for oo languages) that did GC, binding, etc. -- the whole kaboodle --
> in h/w. (Even the microcode talked about objects.) It was hosted by
> a Sun3 (it plugged directly into the backplane). It had its own
> language called Lingo. While waiting for the hardware somebody
> implemented an interpreter in C. By the time Lingo ran on the
> hardware, the interpreter (running on a Sun3) was faster than Lingo
> running on the hardware.

"It will not do to leave a live dragon out of your plans if you live
near one." J.R.R.TOLKIEN in The Hobbit

In this case the dragon is Moore's law being ridden by the main cpu
makers. Add to that the fact that software implementors can easily come
up with new and brilliant ideas to make things faster. Remember:
hardware can know the past but only the compiler can look into the
future!

That said, the Rekursiv was interesting and worth studying:

http://www.brouhaha.com/~eric/retrocomputing/rekursiv/

It did have against it some bad timing - the late 1980s were not very
kind to microcoded machines. It was an era when RISCs ruled the earth.
I think that this became clear to the Mushroom people (Ian, do you have
any comments about your participation in that one?):

http://www.wolczko.com/mushroom/index.html

To answer Tommy Thorn's question about what would be nice to have in a
Smalltalk cpu - the Mushroom used virtually addressed caches. That is,
you passed to the cache the pair {ObjectID, offset} and it would return
a word. You only have to convert the virtual address to a physical
memory address when you have a cache miss. So you can have all kinds of
indirections (object tables, for example) and it doesn't cost you too
much.

Another nice feature was that their generational garbage collector used
the cache exclusively in the youngest generation. So an object could be
created and later collected without causing a single external memory
reference if you got really lucky. As Tim explained the three most
important things are memory bandwidth, memory bandwidth and memory
bandwidth. This was a neat way to get it.

One thing that is annoying if you try to do a cpu to directly execute
bytecodes is that you have two sources of information in the
instructions: the bytecodes themselves and the literals. Most
processors have their literals mixed in the instruction stream, so as
you gobble it up they are right there when you need them.

Another problem with direct bytecode execution is that "you do as you
are told" and execute every single message send implied in the source
code. Modern compilation technology eliminates most sends (Self,
Hotspot Java and StrongTalk). In my smallest design (I am currently
working on three different architectures and have a fourth one that is
paused do to the lack of time) I have a one clock message send and two
clock return (assuming the cache hits), yet the Self compiler can often
get negative message send times! How can you compete with that? The
negative times were obtained by inlining a message send and then using
the new context information to optimize the inlined code so it was far
smaller and faster than the original.

About FPGAs - these didn't improve much through most of the 1990s but
now are advancing at an impressive pace. If you can do something
interesting with an FPGA you get to ride Moore's law with the big boys.
A FPGA with MicroBlaze, Nios or XSOC/xr16 is very competitive in both
price and performance with "normal" embedded processors (at least
between the smallest PICs and the StrongARM). And if you can tweak it
to run something like Smalltalk instead of yet another gcc driven MIPs
clone it really becomes worth it. My smallest machine costs $15 in
single quantities. I'll have some tiny benchmark numbers soon to put
that into the proper perspective.

BTW, what I wrote about hardware/software above supposes that the
hardware can't inline and optimize code, eliminate message sends, etc.
But I figured out how to do exactly that. Unfortunately this email is
too long already.... ;-)

-- Jecel

[Derek Brans]

> Once you've done it you realize that there is a lot of hardware out
> there,
> like wireless cards, cameras, drives, etc. Hardware specs for these
> devices are often unavailable to developers because the vendors
> typically
> supply their own device drivers for the standard OS's. So even if you
> have the time to write your own device drivers, you may lack the
> necessary documentation.

Is there a compromise between "Squeak on bare hardware" and running
Squeak as a process on some other operating system? What about writing
a version of Squeak to operate on a kernel that already exists and is
being ported to many platforms?
Derek

Phasecraft: Smarter Web Development.
Experts in web design, databases, flash design, multi-lingual sites,
branding, marketing and web hosting.
phone: [phone]
mailto:***@phasecraft.com
http://www.phasecraft.com

[JohnMaloney at earthlink.net ()]

At 9:50 AM -0700 10/3/02, Derek Brans wrote:
>> Once you've done it you realize that there is a lot of hardware out
>> there,
>> like wireless cards, cameras, drives, etc. Hardware specs for these
>> devices are often unavailable to developers because the vendors
>> typically
>> supply their own device drivers for the standard OS's. So even if you
>> have the time to write your own device drivers, you may lack the
>> necessary documentation.
>
>Is there a compromise between "Squeak on bare hardware" and running
>Squeak as a process on some other operating system? What about writing
>a version of Squeak to operate on a kernel that already exists and is
>being ported to many platforms?
>Derek

I think building on an OS kernel (such as OSKit, as Tim mentioned) is a
great approach. It gives you excellent control all the way down, but you
can share device driver code with others working on that kernel.

Like Tim, I thought someone out there was doing exactly this. If so, I'd
love to know how it works out.

I'm amazed at the work Luciano's group is doing. Wow!!

-- John

[Marcus Denker]

On Fri, Oct 04, 2002 at 11:25:23AM -0700, ***@earthlink.net wrote:
>
> I think building on an OS kernel (such as OSKit, as Tim mentioned) is a
> great approach. It gives you excellent control all the way down, but you
> can share device driver code with others working on that kernel.
>
> Like Tim, I thought someone out there was doing exactly this. If so, I'd
> love to know how it works out.
>

I did a OSkit-based kernel some time ago. But this was only a weekend
projekt. (It took longer to compile OSKit than to do anything else...)

I've put the stuff at

ftp://ftp.ira.uka.de/pub/squeak/SqueakOS
(I really should rename this...)

the diskimage can be written to a 1.44MB floppy with
ftp://ftp.ira.uka.de/pub/squeak/demo/rawrite2.exe and the thing should
boot on a intel-PC.

The Squeak used is Paul Fernaut's embedded Squeak 2.2 (which had a simple
command-line interface).

OSKit seems to be really nice... you can tailor the kernel just as you
need it, the squeak-kernel uses a very minimal configuration, it's more
like a boot-loader (no Virtual Memory, no Filesystem, not even a scheduler).

But all things needed for a real powefull OS are there: Filesystems,
Networking, Display, Threads, ... and you can simply link with Linux or
FreeBSD drivers.

http://www.cs.utah.edu/flux/oskit/


Marcus


--
Marcus Denker ***@ira.uka.de -- Squeak! http://squeakland.org

[Marcus Denker]

On Fri, Oct 04, 2002 at 11:25:23AM -0700, ***@earthlink.net wrote:
>
> I think building on an OS kernel (such as OSKit, as Tim mentioned) is a
> great approach. It gives you excellent control all the way down, but you
> can share device driver code with others working on that kernel.
>
> Like Tim, I thought someone out there was doing exactly this. If so, I'd
> love to know how it works out.
>

I did a OSkit-based kernel some time ago. But this was only a weekend
projekt. (It took longer to compile OSKit than to do anything else...)

I've put the stuff at

ftp://ftp.ira.uka.de/pub/squeak/SqueakOS
(I really should rename this...)

the diskimage can be written to a 1.44MB floppy with
ftp://ftp.ira.uka.de/pub/squeak/demo/rawrite2.exe and the thing should
boot on a intel-PC.

The Squeak used is Paul Fernaut's embedded Squeak 2.2 (which had a simple
command-line interface).

OSKit seems to be really nice... you can tailor the kernel just as you
need it, the squeak-kernel uses a very minimal configuration, it's more
like a boot-loader (no Virtual Memory, no Filesystem, not even a scheduler).

But all things needed for a real powefull OS are there: Filesystems,
Networking, Display, Threads, ... and you can simply link with Linux or
FreeBSD drivers.

http://www.cs.utah.edu/flux/oskit/


Marcus


--
Marcus Denker ***@ira.uka.de -- Squeak! http://squeakland.org

[Roger Vossler]

Hi Gang,

Back in the early 1980's, Modula Corp. marketed the Lilith workstation
which was
based upon Nicklaus Wirth's work at ETHZ. The Lilith was a bytecode
machine
running MEDOS, an operating environment coded entirely in Modula-2. It
ran
circles around many machines of the day. While the Lilith was a great
piece
of technology, Modula Corp. ran aground on financial, political, and
other issues.

Cheers, Roger.....

On Thursday, Oct 3, 2002, at 22:04 America/Denver, Tim Rowledge wrote:

[snip]

> Exactly; a very special case where the financial logic pushes the other
> way to 'normal' desktop machines. Jecel is one ofthe very very small
> number of peopleI belive could even come close to making special
> purpose
> hardware actually deliver. SUN tried at least acouple of times for java
> nad seem to have failed. SOAR was not very effective, Sword/32 failed,
> iAPX432 was a dog, etc etc. None of which means that nobody will ever
> suceed, it just means I won't be putting any of my millions into the
> project.

[snip]

[Benoit St-Jean]

--- Roger Vossler <***@qwest.net> wrote:
> Hi Gang,
>
> Back in the early 1980's, Modula Corp. marketed the
> Lilith workstation
> which was
> based upon Nicklaus Wirth's work at ETHZ. The Lilith
> was a bytecode
> machine
> running MEDOS, an operating environment coded
> entirely in Modula-2. It
> ran
> circles around many machines of the day. While the
> Lilith was a great
> piece
> of technology, Modula Corp. ran aground on
> financial, political, and
> other issues.

And what a great language Modula-2 was... Brings back
lots of very good memories! :)

=====
-------------------------
Benoit St-Jean
***@yahoo.com
Yahoo! Messenger: bstjean
http://cactus.swiki.net
-------------------------

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

[Alan Kay]

FWIW --

Historical Note --
Klaus Wirth spent a year at PARC learning the Alto. The Lilith
was his version of the Alto and other PARC microcoded bytecoded
machines. Modula was his version of Mesa. The PARC CSL later returned
the favor after they'd moved on to DEC SRC, by creating Modula 3 and
making a very nice multiple processor machine called the Firefly.

Deep Historical Note --
Much earlier in the 60s Klaus did his best work with a typeless
VHLL -- Euler, ca 1965-6 -- that was an extreme generalization of
Algol (based on work by van Wijngaarten). This language had a
bytecode interpreter based on the orginal bytecode interpreter: yes,
the HW of the 1961 Burroughs B5000 designed by Bob Barton. (These are
very old ideas folks.) In 1967 I did to Euler what Simula did to
Algol to get the first Flex language, which was also run by a
microcoded bytecode interpreter (the first OOP one).

Cheers,

Alan

At 7:22 PM -0700 10/5/02, Benoit St-Jean wrote:
>--- Roger Vossler <***@qwest.net> wrote:
>> Hi Gang,
>>
>> Back in the early 1980's, Modula Corp. marketed the
>> Lilith workstation
>> which was
>> based upon Nicklaus Wirth's work at ETHZ. The Lilith
>> was a bytecode
>> machine
>> running MEDOS, an operating environment coded
>> entirely in Modula-2. It
>> ran
>> circles around many machines of the day. While the
>> Lilith was a great
>> piece
>> of technology, Modula Corp. ran aground on
>> financial, political, and
>> other issues.
>
>And what a great language Modula-2 was... Brings back
>lots of very good memories! :)
>
>=====
>-------------------------
>Benoit St-Jean
>***@yahoo.com
>Yahoo! Messenger: bstjean
>http://cactus.swiki.net
>-------------------------
>
>__________________________________________________
>Do you Yahoo!?
>Faith Hill - Exclusive Performances, Videos & More
>http://faith.yahoo.com


--

[Nils Kassube]

I've seen many versions of his name, but "Klaus" is one I've never
seen before. The scientist you're talking about is correctly called
Niklas Wirth :-)

[Alan Kay]

That's what he was called when we knew him at Stanford in the 60s and
PARC in the 70s. He was also called "Bucky" during the Stanford
period.

Cheers,

Alan

------
At 2:01 PM +0200 10/6/02, Nils Kassube wrote:
>I've seen many versions of his name, but "Klaus" is one I've never
>seen before. The scientist you're talking about is correctly called
>Niklas Wirth :-)


--

[Alan Kay]

That's what he was called when we knew him at Stanford in the 60s and
PARC in the 70s. He was also called "Bucky" during the Stanford
period.

Cheers,

Alan

------
At 2:01 PM +0200 10/6/02, Nils Kassube wrote:
>I've seen many versions of his name, but "Klaus" is one I've never
>seen before. The scientist you're talking about is correctly called
>Niklas Wirth :-)


--

[Martin McClure]

At 8:07 PM -0800 10/5/02, Alan Kay wrote:
>
>Deep Historical Note --
> Much earlier in the 60s Klaus did his best work with a typeless
>VHLL -- Euler, ca 1965-6 -- that was an extreme generalization of
>Algol (based on work by van Wijngaarten). This language had a
>bytecode interpreter based on the orginal bytecode interpreter: yes,
>the HW of the 1961 Burroughs B5000 designed by Bob Barton. (These
>are very old ideas folks.) In 1967 I did to Euler what Simula did to
>Algol to get the first Flex language, which was also run by a
>microcoded bytecode interpreter (the first OOP one).
>

I haven't heard anyone mention Euler for a *long* time. When I was
much younger and even more foolish, I liked Euler enough that I chose
write a compiler for Euler for a class assignment. I chose to write
the compiler in Snobol, probably for no better reason than that I
wanted to get a feel for what it was like to write something
non-trivial in Snobol. The result wasn't particularly useful (it took
almost 500K to run the thing, so I had to get time on the mainframe
at night) but I did learn from the experience.

-Martin

[Nils Kassube]

I've seen many versions of his name, but "Klaus" is one I've never
seen before. The scientist you're talking about is correctly called
Niklas Wirth :-)

[Martin McClure]

At 8:07 PM -0800 10/5/02, Alan Kay wrote:
>
>Deep Historical Note --
> Much earlier in the 60s Klaus did his best work with a typeless
>VHLL -- Euler, ca 1965-6 -- that was an extreme generalization of
>Algol (based on work by van Wijngaarten). This language had a
>bytecode interpreter based on the orginal bytecode interpreter: yes,
>the HW of the 1961 Burroughs B5000 designed by Bob Barton. (These
>are very old ideas folks.) In 1967 I did to Euler what Simula did to
>Algol to get the first Flex language, which was also run by a
>microcoded bytecode interpreter (the first OOP one).
>

I haven't heard anyone mention Euler for a *long* time. When I was
much younger and even more foolish, I liked Euler enough that I chose
write a compiler for Euler for a class assignment. I chose to write
the compiler in Snobol, probably for no better reason than that I
wanted to get a feel for what it was like to write something
non-trivial in Snobol. The result wasn't particularly useful (it took
almost 500K to run the thing, so I had to get time on the mainframe
at night) but I did learn from the experience.

-Martin

[Alan Kay]

FWIW --

Historical Note --
Klaus Wirth spent a year at PARC learning the Alto. The Lilith
was his version of the Alto and other PARC microcoded bytecoded
machines. Modula was his version of Mesa. The PARC CSL later returned
the favor after they'd moved on to DEC SRC, by creating Modula 3 and
making a very nice multiple processor machine called the Firefly.

Deep Historical Note --
Much earlier in the 60s Klaus did his best work with a typeless
VHLL -- Euler, ca 1965-6 -- that was an extreme generalization of
Algol (based on work by van Wijngaarten). This language had a
bytecode interpreter based on the orginal bytecode interpreter: yes,
the HW of the 1961 Burroughs B5000 designed by Bob Barton. (These are
very old ideas folks.) In 1967 I did to Euler what Simula did to
Algol to get the first Flex language, which was also run by a
microcoded bytecode interpreter (the first OOP one).

Cheers,

Alan

At 7:22 PM -0700 10/5/02, Benoit St-Jean wrote:
>--- Roger Vossler <***@qwest.net> wrote:
>> Hi Gang,
>>
>> Back in the early 1980's, Modula Corp. marketed the
>> Lilith workstation
>> which was
>> based upon Nicklaus Wirth's work at ETHZ. The Lilith
>> was a bytecode
>> machine
>> running MEDOS, an operating environment coded
>> entirely in Modula-2. It
>> ran
>> circles around many machines of the day. While the
>> Lilith was a great
>> piece
>> of technology, Modula Corp. ran aground on
>> financial, political, and
>> other issues.
>
>And what a great language Modula-2 was... Brings back
>lots of very good memories! :)
>
>=====
>-------------------------
>Benoit St-Jean
>***@yahoo.com
>Yahoo! Messenger: bstjean
>http://cactus.swiki.net
>-------------------------
>
>__________________________________________________
>Do you Yahoo!?
>Faith Hill - Exclusive Performances, Videos & More
>http://faith.yahoo.com


--

[Derek Brans]

How difficult would it be to turn Squeak into an OS? Has there been any
discussion / papers about this that someone can point me to?

Thanks,
Derek

Phasecraft: Smarter Web Development.
Experts in web design, databases, flash design, multi-lingual sites,
branding, marketing and web hosting.
phone: [phone]
mailto:***@phasecraft.com
http://www.phasecraft.com

[John M McIntosh]

I recall at last year's OOPSLA Ian was showing off a squeak image that
he was
booting via open firmware. Basically he was using open firmware on an
apple
powerbook to load a VM and an image instead of a commerical/opensource
Operating system.

I believe by use of some of the open firmware drives
(disk/network/video) he was able to manage
quite a bit without having to write drivers etc.

If someone really really needs this they should ask Ian for a copy I'd
guess.

Looked like a good way to do kioks software and not worry about OS
issues.

On Thursday, October 3, 2002, at 08:50 AM, ***@earthlink.net
wrote:

> Re:
>> And of course, this wonderful code is buried somewhere to never be
>> used
>> again. The wonders of propietary closed source software. Interval has
>> donated some things, but if they didn't want to use a RTOS Squeak,
>> what
>> makes them think someone else ever will? ( Why hold on to dead project
>> code? No one is gonna buy it! Set it free! ).
>
--
========================================================================
===
John M. McIntosh <***@smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===

[Ian Piumarta]

On Thu, 3 Oct 2002, John M McIntosh wrote:

> I recall at last year's OOPSLA Ian was showing off a squeak image that
> he was booting via open firmware. Basically he was using open
> firmware on an apple powerbook to load a VM and an image instead of a
> commerical/opensource Operating system. I believe by use of some of
> the open firmware drives (disk/network/video) he was able to manage
> quite a bit without having to write drivers etc.

OF gives you very limited functionality: just enough disk i/o to boot a
kernel and just enough console/keyboard to ask the uer where to look for
that kernel. After that you're pretty much on your own for mapping memory
and doing anything other than text console and keyboard -- there's no
mouse, for example, or graphics driver. OF's only really contribution to
your running kerner is that it has laready probed the hardware and built
you a device tree describing what's there. Configuring, enabling and then
using the devices is clearly the responsibility of your kernel not OF.

For Squeak I had to write my own mouse driver, the image was compressed
and placed in its own segment of `VM kernel' (no sources/changes) and I
almost got enough of the colourmap initialised to display the screen
correctly (although console framebuffers have a hard time with the notion
of `transparency' ;). But anyone who was there will remember the video
projector not wanting to display anything coming out of the vga connector.

> If someone really really needs this they should ask Ian for a copy I'd
> guess. Looked like a good way to do kioks software and not worry
> about OS issues.

You can only not worry up to the point where OF hands control to your
`kernel'. From that point on you're expected to do pretty much
everything, starting with mapping yourself some real memory and deciding
how you're going to deal with (raw!) interrupts, etc...

Ian

[Luciano Notarfrancesco]

Hey Tim,

Tim wrote:
> Exactly. Not to mention that writing a tcp/ip stack
> is a bit of a labour. Why not use one that has
> already been written and tested? That's why I tend
> to think that using the OSKit is a good idea. It
> allows use of linux device drivers and so on.
> Big savings in effort. SqueakNOS is an excellent
> project using this approach.

Actually, we took exactly the opposite approach. Not
the OSKit or Linux approach. We've implemented all the
drivers in Squeak. We're handling interrupts (all of
them, except the clock IRQ) in Squeak, via a Semaphore
that is signaled in a generic IRQ handler in the VM.
We've implemented drivers for the serial port,
keyboard and PS/2 mouse. We have classes with names
like PIC8259 (the Programmable Interrupt Controller),
PCKeyboard, UART8250, UART16550, etc. This is crazy, I
know, it's a lot of fun. It is great to be able to
speak directly to the hardware objects from Squeak,
sending them messages and making it crash sometimes :)

It's funny that you mention the project of writing a
TCP/IP stack in Smalltalk from scratch. I've been
doing exactly that in my spare time, and it works, or
kind of (ARP, IP and UDP are working fine, and TCP is
almost there, but with no fany stuff like delayed
ACKs). We implemented SLIP over the UART8250 and were
able to ping SqueakNOS from a Linux box.

But please don't compare this homegrown OS to the
Interval SqueakOS. We're four or five persons (from
Argentina) working on our spare time, and the last
time we got together to do put some work on SqueakNOS
was like 6 o 8 months ago.

Cheers,
Luciano.-

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[Ian Piumarta]

On Thu, 3 Oct 2002, Tim Rowledge wrote:

> SUN tried at least acouple of times for java nad seem to have failed.
> SOAR was not very effective, Sword/32 failed, iAPX432 was a dog, etc
> etc.

I worked for a while on the REKURSIV project (a microcoded chipset for oo
languages) that did GC, binding, etc. -- the whole kaboodle -- in h/w.
(Even the microcode talked about objects.) It was hosted by a Sun3 (it
plugged directly into the backplane). It had its own language called
Lingo. While waiting for the hardware somebody implemented an interpreter
in C. By the time Lingo ran on the hardware, the interpreter (running on
a Sun3) was faster than Lingo running on the hardware.

The front-end was out-performing the mainframe.

To misquote (severely) Eliot Miranda: the portable (software) version was
faster than the platform-specific (hardware) version by virtue of its
portability.

That's enough irrelevance for one day... Over and out,

Ian

[Derek Brans]

> Once you've done it you realize that there is a lot of hardware out
> there,
> like wireless cards, cameras, drives, etc. Hardware specs for these
> devices are often unavailable to developers because the vendors
> typically
> supply their own device drivers for the standard OS's. So even if you
> have the time to write your own device drivers, you may lack the
> necessary documentation.

Is there a compromise between "Squeak on bare hardware" and running
Squeak as a process on some other operating system? What about writing
a version of Squeak to operate on a kernel that already exists and is
being ported to many platforms?
Derek

Phasecraft: Smarter Web Development.
Experts in web design, databases, flash design, multi-lingual sites,
branding, marketing and web hosting.
phone: [phone]
mailto:***@phasecraft.com
http://www.phasecraft.com

[squeak-dev at lists.squeakfoundation.org ()]

At 9:50 AM -0700 10/3/02, Derek Brans wrote:
>> Once you've done it you realize that there is a lot of hardware out
>> there,
>> like wireless cards, cameras, drives, etc. Hardware specs for these
>> devices are often unavailable to developers because the vendors
>> typically
>> supply their own device drivers for the standard OS's. So even if you
>> have the time to write your own device drivers, you may lack the
>> necessary documentation.
>
>Is there a compromise between "Squeak on bare hardware" and running
>Squeak as a process on some other operating system? What about writing
>a version of Squeak to operate on a kernel that already exists and is
>being ported to many platforms?
>Derek

I think building on an OS kernel (such as OSKit, as Tim mentioned) is a
great approach. It gives you excellent control all the way down, but you
can share device driver code with others working on that kernel.

Like Tim, I thought someone out there was doing exactly this. If so, I'd
love to know how it works out.

I'm amazed at the work Luciano's group is doing. Wow!!

-- John

[Roger Vossler]

Hi Gang,

Back in the early 1980's, Modula Corp. marketed the Lilith workstation
which was
based upon Nicklaus Wirth's work at ETHZ. The Lilith was a bytecode
machine
running MEDOS, an operating environment coded entirely in Modula-2. It
ran
circles around many machines of the day. While the Lilith was a great
piece
of technology, Modula Corp. ran aground on financial, political, and
other issues.

Cheers, Roger.....

On Thursday, Oct 3, 2002, at 22:04 America/Denver, Tim Rowledge wrote:

[snip]

> Exactly; a very special case where the financial logic pushes the other
> way to 'normal' desktop machines. Jecel is one ofthe very very small
> number of peopleI belive could even come close to making special
> purpose
> hardware actually deliver. SUN tried at least acouple of times for java
> nad seem to have failed. SOAR was not very effective, Sword/32 failed,
> iAPX432 was a dog, etc etc. None of which means that nobody will ever
> suceed, it just means I won't be putting any of my millions into the
> project.

[snip]

[Benoit St-Jean]

--- Roger Vossler <***@qwest.net> wrote:
> Hi Gang,
>
> Back in the early 1980's, Modula Corp. marketed the
> Lilith workstation
> which was
> based upon Nicklaus Wirth's work at ETHZ. The Lilith
> was a bytecode
> machine
> running MEDOS, an operating environment coded
> entirely in Modula-2. It
> ran
> circles around many machines of the day. While the
> Lilith was a great
> piece
> of technology, Modula Corp. ran aground on
> financial, political, and
> other issues.

And what a great language Modula-2 was... Brings back
lots of very good memories! :)

=====
-------------------------
Benoit St-Jean
***@yahoo.com
Yahoo! Messenger: bstjean
http://cactus.swiki.net
-------------------------

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com