would it be fun to implement Squeak on this hardware?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

ccrraaiigg

> Why not strip the VM down as far as possible too, and pull in
> additional things when needed?  Just enough VM to run a minimal
> Spoon. It doesn't have to be fast; it can pull in speedup methods
> as needed (or perhaps even swap itself for a fancier VM on the
> fly???).

     Sure, that's the plan. I first asked someone to help with that in
1998. It's not hard. No one has decided to devote time to it. Now's your
chance. :)


-C

--
Craig Latta
www.netjam.org/resume
+1 510 984 8117
(Skype rings this until 31 January 2014)


Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Doug Jones
On 12/22/2013 03:24 PM, Craig Latta wrote:

>
>> Why not strip the VM down as far as possible too, and pull in
>> additional things when needed?  Just enough VM to run a minimal
>> Spoon. It doesn't have to be fast; it can pull in speedup methods
>> as needed (or perhaps even swap itself for a fancier VM on the
>> fly???).
>
>       Sure, that's the plan. I first asked someone to help with that in
> 1998. It's not hard. No one has decided to devote time to it. Now's your
> chance. :)
>


If all goes to plan I should be getting one of these boards by March.
I've already thought of a number of things to try out on it.  One of my
weirder ideas is to use the existing Python implementation to somehow
bootstrap other VMs on this hardware.  Not that I have any idea how to
do this...  But it's fun to think about...

Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Bert Freudenberg
In reply to this post by ccrraaiigg
On 2013-12-23, at 00:24, Craig Latta <[hidden email]> wrote:

>> Why not strip the VM down as far as possible too, and pull in
>> additional things when needed?  Just enough VM to run a minimal
>> Spoon. It doesn't have to be fast; it can pull in speedup methods
>> as needed (or perhaps even swap itself for a fancier VM on the
>> fly???).
>
>     Sure, that's the plan. I first asked someone to help with that in
> 1998. It's not hard. No one has decided to devote time to it. Now's your
> chance. :)

One thing would be to compile the VM without inlining. Another to remove the non-essential primitives, which have a fallback in image (*). Even more primitives could be made optional if the image had more fallbacks. Or if you knew the image wasn't going to use those primitives, which might be the case in Spoon. Also quite a bit of code is devoted to purely to optimizing - the method cache, at-caches etc.

- Bert -

(*) but don't be surprised if the fallback code suffers from bitrot. It is never executed on regular VMs with all the primitives in place. Having recently implemented a minimal VM I did discover those bugs ;)
Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Nicolas Cellier

2013/12/23 Bert Freudenberg <[hidden email]>
On 2013-12-23, at 00:24, Craig Latta <[hidden email]> wrote:

>> Why not strip the VM down as far as possible too, and pull in
>> additional things when needed?  Just enough VM to run a minimal
>> Spoon. It doesn't have to be fast; it can pull in speedup methods
>> as needed (or perhaps even swap itself for a fancier VM on the
>> fly???).
>
>     Sure, that's the plan. I first asked someone to help with that in
> 1998. It's not hard. No one has decided to devote time to it. Now's your
> chance. :)

One thing would be to compile the VM without inlining. Another to remove the non-essential primitives, which have a fallback in image (*). Even more primitives could be made optional if the image had more fallbacks. Or if you knew the image wasn't going to use those primitives, which might be the case in Spoon. Also quite a bit of code is devoted to purely to optimizing - the method cache, at-caches etc.

- Bert -

(*) but don't be surprised if the fallback code suffers from bitrot. It is never executed on regular VMs with all the primitives in place. Having recently implemented a minimal VM I did discover those bugs ;)

Yep, I saw at least one when I failed to change some primitive and made it accidentally fail.
For better testability, we could isolate the fallback code under a separate method, but that would consume a bunch of selectors and somehow be contradictory with a principle of economy - less is more.



Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Bert Freudenberg
On 2013-12-23, at 15:02, Nicolas Cellier <[hidden email]> wrote:

> 2013/12/23 Bert Freudenberg <[hidden email]>
>>  don't be surprised if the fallback code suffers from bitrot. It is never executed on regular VMs with all the primitives in place. Having recently implemented a minimal VM I did discover those bugs ;)
>
> Yep, I saw at least one when I failed to change some primitive and made it accidentally fail.
> For better testability, we could isolate the fallback code under a separate method, but that would consume a bunch of selectors and somehow be contradictory with a principle of economy - less is more.

For testing you could temporarily set the CompiledMethod's primitive index to 0.

- Bert -



Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Bob Hartwig-2
What makes the Micro Python board more attractive than the BeagleBone Black, which is just as open, and orders of magnitude more capable?  I understand the appeal of targeting really tiny hardware like 8-bit microcontrollers, but I don't understand the appeal of this middle-of-the-road board.  But I may be missing something.

    Bob



On Mon, Dec 23, 2013 at 8:27 AM, Bert Freudenberg <[hidden email]> wrote:
On 2013-12-23, at 15:02, Nicolas Cellier <[hidden email]> wrote:

> 2013/12/23 Bert Freudenberg <[hidden email]>
>>  don't be surprised if the fallback code suffers from bitrot. It is never executed on regular VMs with all the primitives in place. Having recently implemented a minimal VM I did discover those bugs ;)
>
> Yep, I saw at least one when I failed to change some primitive and made it accidentally fail.
> For better testability, we could isolate the fallback code under a separate method, but that would consume a bunch of selectors and somehow be contradictory with a principle of economy - less is more.

For testing you could temporarily set the CompiledMethod's primitive index to 0.

- Bert -






Reply | Threaded
Open this post in threaded view
|

open source hardware (was: would it be fun to implement Squeak (and SPOON!) on this hardware?)

Jecel Assumpcao Jr
In reply to this post by Doug Jones
Doug Jones wrote:
> [...]
> - completely open source hardware, not very expensive, and practical for
> a hobbyist board builder as well as mass production

Wouldn't it be better to use the term "open source software friendly
hardware" instead of "open source hardware" for this? It seems that the
Free Software Foundation adopted the term "Respects Your Freedom" (RYF)
for the first hardware they have ever certified:

> http://www.fsf.org/news/gluglug-x60-laptop-now-certified-to-respect-your-freedom

It certainly seems very odd to call anything with an ARM or Intel
processor "open source hardware". If we do that, then what would we call
something like:

http://opencores.org/donation

?

Note that the low amount that has been pledged so far ($22K) shows how
little people actually value this kind of thing no matter what they say.
Of course, if they had gone with Kickstarter instead of their own
(obscure) web site they might have had a far better result, so perhaps I
am reading too much into this.

-- Jecel
p.s.: the binary for the Linux version of the Little Smalltalk 3 VM is
only 55KB with everything statically linked in


Reply | Threaded
Open this post in threaded view
|

re: open source hardware

ccrraaiigg
In reply to this post by Doug Jones

Hi Jecel--

> http://opencores.org/donation
>
> Note that the low amount that has been pledged so far ($22K) shows how
> little people actually value this kind of thing no matter what they
> say. Of course, if they had gone with Kickstarter instead of their own
> (obscure) web site they might have had a far better result, so
> perhaps I am reading too much into this.

     I suspect so, although I spend my time in Amsterdam and San
Francisco, where the interest level may be skewed higher. :)

> the binary for the Linux version of the Little Smalltalk 3 VM is only
> 55KB with everything statically linked in

     Cool! Yeah, I'm sure there's a tiny VM in Squeak waiting to get out...


-C

--
Craig Latta
www.netjam.org/resume
+1 510 984 8117
(Skype rings this until 31 January 2014)


Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Jon Hylands
In reply to this post by Bob Hartwig-2
The real win over the Beaglebone Black (I have one of those too) is that there is no complication of the OS, and it boots instantly when you turn on the power. You're working on the metal, which can be fun in some cases.

- Jon



On Mon, Dec 23, 2013 at 10:23 AM, Bob Hartwig <[hidden email]> wrote:
What makes the Micro Python board more attractive than the BeagleBone Black, which is just as open, and orders of magnitude more capable?  I understand the appeal of targeting really tiny hardware like 8-bit microcontrollers, but I don't understand the appeal of this middle-of-the-road board.  But I may be missing something.

    Bob



On Mon, Dec 23, 2013 at 8:27 AM, Bert Freudenberg <[hidden email]> wrote:
On 2013-12-23, at 15:02, Nicolas Cellier <[hidden email]> wrote:

> 2013/12/23 Bert Freudenberg <[hidden email]>
>>  don't be surprised if the fallback code suffers from bitrot. It is never executed on regular VMs with all the primitives in place. Having recently implemented a minimal VM I did discover those bugs ;)
>
> Yep, I saw at least one when I failed to change some primitive and made it accidentally fail.
> For better testability, we could isolate the fallback code under a separate method, but that would consume a bunch of selectors and somehow be contradictory with a principle of economy - less is more.

For testing you could temporarily set the CompiledMethod's primitive index to 0.

- Bert -










Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

timrowledge

On 23-12-2013, at 4:00 PM, Jon Hylands <[hidden email]> wrote:

> The real win over the Beaglebone Black (I have one of those too) is that there is no complication of the OS, and it boots instantly when you turn on the power. You're working on the metal, which can be fun in some cases.

Run RISC OS. It’s about as close to bare metal as you can get and still have a helpful OS around to start from. Unlike unixy OSs it lets you get straight to the metal; no ring 0 authorisation hoops to jump through.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Trojan:  Storage device for replicating codes...



Reply | Threaded
Open this post in threaded view
|

Re: open source hardware

Doug Jones
In reply to this post by Doug Jones
On 12/23/2013 09:07 AM, Jecel Assumpcao Jr. wrote:

> Doug Jones wrote:
>> [...]
>> - completely open source hardware, not very expensive, and practical for
>> a hobbyist board builder as well as mass production
>
> Wouldn't it be better to use the term "open source software friendly
> hardware" instead of "open source hardware" for this? It seems that the
> Free Software Foundation adopted the term "Respects Your Freedom" (RYF)
> for the first hardware they have ever certified:
>
>> http://www.fsf.org/news/gluglug-x60-laptop-now-certified-to-respect-your-freedom
>
> It certainly seems very odd to call anything with an ARM or Intel
> processor "open source hardware". If we do that, then what would we call
> something like:
>
> http://opencores.org/donation
>
> ?
>
> Note that the low amount that has been pledged so far ($22K) shows how
> little people actually value this kind of thing no matter what they say.
> Of course, if they had gone with Kickstarter instead of their own
> (obscure) web site they might have had a far better result, so perhaps I
> am reading too much into this.
>
> -- Jecel
> p.s.: the binary for the Linux version of the Little Smalltalk 3 VM is
> only 55KB with everything statically linked in
>
>
>


You're right of course.  Earlier in the thread I said something like
"open source hardware, as much as possible", which is more accurate but
still a bit vague.  But then got sloppier in later posts.

It's open to the extent that the board design is open, and there are
enough freely available docs available so that designing with the SOC is
not a pain.

There are barriers to open hardware no matter where you look right now.
  You could design with an open CPU design that even the FSF would like,
but the choices in that direction are currently very limited and impose
compromises that add up to a type of barrier (can I buy a chip for $10
and solder it onto a PCB board I milled in my garage, and do as much
with it as I could with the Micro Python?)

The gluglug is a good development, but it also has a CPU chip that
contains proprietary circuits.  They are just packaging it without
binary blobs.  The same is true for the Micro Python board, and
apparently also the laptop Laribel looked at the other day:

http://www.phoronix.com/scan.php?page=article&item=acer_c720_linux&num=1

(except for the touchpad driver, which hopefully somebody will replace
soon with an open one).

And it gladdened my heart to hear the rumor going around that they're
getting ready to ditch the binary blob required to boot up the Raspberry Pi.

What I want is a CPU chip that has a completely open internal design, is
cheap, and as powerful as the other chips in its price range.  Until
that becomes available, I find myself compromising here and there...

Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Bob Hartwig-2
In reply to this post by timrowledge
Why not program the BBB's bare metal?  Too much error-prone hassle to initialize everything?

    Bob




On Mon, Dec 23, 2013 at 7:17 PM, tim Rowledge <[hidden email]> wrote:

On 23-12-2013, at 4:00 PM, Jon Hylands <[hidden email]> wrote:

> The real win over the Beaglebone Black (I have one of those too) is that there is no complication of the OS, and it boots instantly when you turn on the power. You're working on the metal, which can be fun in some cases.

Run RISC OS. It’s about as close to bare metal as you can get and still have a helpful OS around to start from. Unlike unixy OSs it lets you get straight to the metal; no ring 0 authorisation hoops to jump through.
Trojan:  Storage device for replicating codes...






Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Doug Jones
In reply to this post by Bob Hartwig-2
On 12/23/2013 07:23 AM, Bob Hartwig wrote:
> What makes the Micro Python board more attractive than the BeagleBone
> Black, which is just as open, and orders of magnitude more capable?  I
> understand the appeal of targeting really tiny hardware like 8-bit
> microcontrollers, but I don't understand the appeal of this
> middle-of-the-road board.  But I may be missing something.
>
>      Bob
>

Targeting the BeagleBone Black would be good too.  I like that hardware.

The Micro Python is a different class of computer.  It has no video out,
no graphics processor.  It doesn't come in a ball grid package that I
couldn't possibly solder onto a board.  It can achieve much lower power
consumption levels.  I suspect nobody will ever get Linux running on it.

It has an open source software distribution running on it that boots
from bare metal all the way to a high-level language command line,
perhaps in less than 20,000 lines of code (I haven't actually counted,
but I wouldn't be surprised given how long it took him to write it, and
anyway I like that magical number).  Does the BeagleBone Black have that?

Spoon has the potential to run on really small hardware.  Getting it
running on an Arduino would be a real challenge, given the tiny amount
of RAM that chip has, but doing it with 192KB of RAM might be achievable
without excessive pain.

Seems to me this kind of hardware occupies a Spoon sweet spot.  It's not
so small that the port would be really hard;  it's just big enough to do
everything a minimal Spoon machine needs to do, while still being
accessible to people who don't have a lot of money to spend on it.
Hobbyists can even build their own without needing to call a PCB board
maker.

The Arduino has opened up a whole new class of computing to people.  We
can buy them cheaply or build them.  We can easily make new designs with
new functionality.  We can use open tools on it.  Now it's in a zillion
3D printers and lots of other things.  But it's slow, memory is quite
limited and it's programmed in a fairly low-level language.

Now we can step up from the Arduino to something only a little more
expensive, but still very accessible to individuals and small shops.
Substantially faster, more RAM, floating point hardware, and
programmable in high-level languages.  And still with Arduino's
collection of programmable IO pins.

The big barrier we kick down with these is the language barrier.
Letting the user program it in Python opens the platform up to a whole
new group of users who aren't comfortable with the low-level languages
on Arduino-class machines.  And if it can do Python, it can do other
languages.

So that's the idea:  Put Spoon on the smallest machine it will
comfortably fit on, hopefully with way less than 20,000 lines of code in
total.  Get a bunch of them talking to each other, and to the bigger
machines already running Spoon.  See what ideas people come up with for
using it.








>
>
> On Mon, Dec 23, 2013 at 8:27 AM, Bert Freudenberg <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 2013-12-23, at 15:02, Nicolas Cellier
>     <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>      > 2013/12/23 Bert Freudenberg <[hidden email]
>     <mailto:[hidden email]>>
>      >>  don't be surprised if the fallback code suffers from bitrot. It
>     is never executed on regular VMs with all the primitives in place.
>     Having recently implemented a minimal VM I did discover those bugs ;)
>      >
>      > Yep, I saw at least one when I failed to change some primitive
>     and made it accidentally fail.
>      > For better testability, we could isolate the fallback code under
>     a separate method, but that would consume a bunch of selectors and
>     somehow be contradictory with a principle of economy - less is more.
>
>     For testing you could temporarily set the CompiledMethod's primitive
>     index to 0.
>
>     - Bert -
>
>
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Doug Jones
In reply to this post by Bob Hartwig-2
On 12/23/2013 07:18 PM, Bob Hartwig wrote:
> Why not program the BBB's bare metal?  Too much error-prone hassle to
> initialize everything?
>
>      Bob


Why not indeed?  I like that plan too.  But somebody has to start, and
then do all that work.

This Micro Python thing is already running.  It's got a working
codebase, a community building up behind it, and substantial funding.  I
can think of worse things to bootstrap on top of.

There are motivational things at work here.  Sure, you can work on
building a minimal Spoon and a minimal VM on a PC-class machine with
gigs of RAM and millions of lines of OS code underneath it.  But if you
build it on a really tiny machine, a different kind of pressure builds
up in your brain.

I like the idea of getting Spoon running on lots of different kinds of
machines.  But given the number of people willing to work on Spoon so
far, it seems unproductive to target a bunch of platforms all at once.
Targeting a minimal hardware platform is a good way of keeping work
focussed on Craig's original goals for Spoon.  The fact that it has no
video out is a positive boon.





Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

Jon Hylands
In reply to this post by Bob Hartwig-2
That, plus having to write your own drivers to talk to anything useful is the real reason I like working with lower level processors. The bare metal is much more accessible in an AVR (and also an ARM7). When I have as much power as the BBB gives, I want Linux, because I want to plug in wifi dongles and usb devices and so on. I spend at least half my time on my BBB trying to configure drivers and subsystems, trying to make it work and keep it working each time it boots up.

As another side, the BBB is huge (compared to, say, a Teensy 3.1). It simply won't fit into the class of robot I'm building around the Teensy. Check out my blog (http://blog.huv.com) for some pictures.

- Jon



On Mon, Dec 23, 2013 at 10:18 PM, Bob Hartwig <[hidden email]> wrote:
Why not program the BBB's bare metal?  Too much error-prone hassle to initialize everything?

    Bob




On Mon, Dec 23, 2013 at 7:17 PM, tim Rowledge <[hidden email]> wrote:

On 23-12-2013, at 4:00 PM, Jon Hylands <[hidden email]> wrote:

> The real win over the Beaglebone Black (I have one of those too) is that there is no complication of the OS, and it boots instantly when you turn on the power. You're working on the metal, which can be fun in some cases.

Run RISC OS. It’s about as close to bare metal as you can get and still have a helpful OS around to start from. Unlike unixy OSs it lets you get straight to the metal; no ring 0 authorisation hoops to jump through.
Trojan:  Storage device for replicating codes...










Reply | Threaded
Open this post in threaded view
|

Re: open source hardware

Jecel Assumpcao Jr
In reply to this post by Doug Jones
Doug,

> What I want is a CPU chip that has a completely open internal design, is
> cheap, and as powerful as the other chips in its price range.  Until
> that becomes available, I find myself compromising here and there...

I am working on it, but don't hold your breath.

-- Jecel


Reply | Threaded
Open this post in threaded view
|

re: would it be fun to implement Squeak (and SPOON!) on this hardware?

ccrraaiigg
In reply to this post by Doug Jones

Hi Doug--

> I like the idea of getting Spoon running on lots of different kinds of
> machines.  But given the number of people willing to work on Spoon so
> far, it seems unproductive to target a bunch of platforms all at once.
> Targeting a minimal hardware platform is a good way of keeping work
> focused on Craig's original goals for Spoon.  The fact that it has no
> video out is a positive boon.

     :)

> Seems to me this kind of hardware occupies a Spoon sweet spot.  It's
> not so small that the port would be really hard;  it's just big
> enough to do everything a minimal Spoon machine needs to do, while
> still being accessible to people who don't have a lot of money to
> spend on it. Hobbyists can even build their own without needing to
> call a PCB board maker.

     I want to reiterate that I'd love to collaborate on getting Spoon
running on all these little platforms. We could use the method-marking
stuff on the virtual machine simulator to identify the minimal set of
primitives/instructions/plugins/etc. I think I've only been using
LargeIntegers, MiscPrimitives, and Flow.


-C

--
Craig Latta
www.netjam.org/resume
+1 510 984 8117
(Skype rings this until 31 January 2014)


12