> 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) |
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... |
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 ;) |
2013/12/23 Bert Freudenberg <[hidden email]>
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. |
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 - |
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: |
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 |
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) |
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. - JonOn Mon, Dec 23, 2013 at 10:23 AM, Bob Hartwig <[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. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Trojan: Storage device for replicating codes... |
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... |
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:
|
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 - > > > > > > > |
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. |
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.On Mon, Dec 23, 2013 at 10:18 PM, Bob Hartwig <[hidden email]> wrote:
|
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 |
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) |
Free forum by Nabble | Edit this page |