Reuben Thomas | 7 Feb 12:49 2012

Re: Raspberry Pi

On 7 February 2012 11:34, Ryan Mitchley <ryan.mitchley@...> wrote:
>
> I think the limited capabilities would be a great visceral demonstration of
> the efficiencies learned during the FONC research.
>
> I was thinking in terms of replacing the GNU software, using it as a cheap
> hardware target... some FONC-based system should blow the GNU stack out of
> the water when resources are restricted.

Now that's an exciting idea.

--

-- 
http://rrt.sc3d.org
Jecel Assumpcao Jr. | 7 Feb 18:42 2012

Re: Raspberry Pi

Reuben Thomas wrote:
> On 7 February 2012 11:34, Ryan Mitchley wrote:
> >
> > I think the limited capabilities would be a great visceral demonstration of
> > the efficiencies learned during the FONC research.
> >
> > I was thinking in terms of replacing the GNU software, using it as a cheap
> > hardware target... some FONC-based system should blow the GNU stack out of
> > the water when resources are restricted.
> 
> Now that's an exciting idea.

People complain about *only* having 256MB (128MB in the A model) but
that is way more than is needed for SqueakNOS and, I imagine, Frank.
Certainly the boot time for SqueakNOS would be a second or less on this
hardware, which should impress a few people when compared to the various
Linux on the same board.

Fortunately, some information needed to port an OS to the Raspberry Pi
was released yesterday:

> http://dmkenr5gtnd8f.cloudfront.net/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

The GPU stuff is still secret but I don't think the current version of
Frank would make use of it anyway.

-- Jecel

Alan Kay | 7 Feb 18:19 2012
Picon

Re: Raspberry Pi

Hi Jecel

In the "difference between research and engineering department" I think I would first port a version of Smalltalk to this system.

One of the fun side-projects done in the early part of the Squeak system was when John Maloney and a Berkeley grad student ported Squeak to "a luggage tag" -- that is to the Mitsubishi hybrid "computer on a chip" that existed back ca 1997. This was a ARM-like 32 bit microprocessor plus 4MB (or more) memory on a single die. This plus one ASIC constituted the whole computer.

Mitsubishi did this nice system for mobile use. Motorola bought the rights to this technology and completely buried it to kill competition.

(We call it the "luggage tag" because they would embed failed chips in Lucite to make luggage tags!)

Anyway, for fun John and the grad student ported Squeak to this bare chip (including having to write the BiOS code). It worked fine, and I was able to do a large scale Etoy demo on it.

Although Squeak was quite small in those days, a number of effective optimizations had been done at various levels, and so it was quite efficient, and all plus Etoys fit easily into 4MB. 

In the earliest days of the OLPC XO project we made an offer to make Squeak the entire OS of the XO, etc., but you can imagine the resistance!

Frank on the other hand has very few optimizations -- it is about lines of code that carry meaning. It is a goal of the project to "separate optimizations from the meanings" so it would still run with the optimizations turned off but slower. We have done very little of this so far, and very few optimizations. We can give live dynamic demos in part because Dan Amelang's Nile graphics system turned out to be more efficient than we thought with very few optimizations.

I think it could be an valuable project for interested parties to see about how to organize the separate "optimization spaces" that use the meanings as references.

Cheers,

Alan


From: Jecel Assumpcao Jr. <jecel-/J8iz1DznIp8UrSeD/g0lQ@public.gmane.org>
To: Fundamentals of New Computing <fonc-uVco7kAcSAQ@public.gmane.org>
Sent: Tuesday, February 7, 2012 9:42 AM
Subject: Re: [fonc] Raspberry Pi

Reuben Thomas wrote:
> On 7 February 2012 11:34, Ryan Mitchley wrote:
> >
> > I think the limited capabilities would be a great visceral demonstration of
> > the efficiencies learned during the FONC research.
> >
> > I was thinking in terms of replacing the GNU software, using it as a cheap
> > hardware target... some FONC-based system should blow the GNU stack out of
> > the water when resources are restricted.
>
> Now that's an exciting idea.

People complain about *only* having 256MB (128MB in the A model) but
that is way more than is needed for SqueakNOS and, I imagine, Frank.
Certainly the boot time for SqueakNOS would be a second or less on this
hardware, which should impress a few people when compared to the various
Linux on the same board.

Fortunately, some information needed to port an OS to the Raspberry Pi
was released yesterday:

> http://dmkenr5gtnd8f.cloudfront.net/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

The GPU stuff is still secret but I don't think the current version of
Frank would make use of it anyway.

-- Jecel

_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


<div><div>
<div><span>Hi Jecel</span></div>
<div>
<br><span></span>
</div>
<div><span>In the "difference between research and engineering department" I think I would first port a version of Smalltalk to this system. <br></span></div>
<div><span><br></span></div>
<div><span>One of the fun side-projects done in the early part of the Squeak system was when John Maloney and a Berkeley grad student ported Squeak to "a luggage tag" -- that is to the Mitsubishi hybrid "computer on a chip" that existed back ca 1997. This was a ARM-like 32 bit microprocessor plus 4MB (or more) memory on a single die. This plus one ASIC constituted the whole computer. <br></span></div>
<div><span><br></span></div>
<div><span>Mitsubishi did this nice system for mobile use. Motorola bought the rights to this technology and completely buried it to kill
 competition.</span></div>
<div>
<br><span></span>
</div>
<div><span>(We call it the "luggage tag" because they would embed failed chips in Lucite to make luggage tags!)</span></div>
<div>
<br><span></span>
</div>
<div><span>Anyway, for fun John and the grad student ported Squeak to this bare chip (including having to write the BiOS code). It worked fine, and I was able to do a large scale Etoy demo on it.</span></div>
<div>
<br><span></span>
</div>
<div><span>Although Squeak was quite small in those days, a number of effective optimizations had been done at various levels, and so it was quite efficient, and all plus Etoys fit easily into 4MB.&nbsp;</span></div>
<div>
<br><span></span>
</div>
<div><span>In the earliest days of the OLPC XO project we made an offer to make Squeak the entire OS of the XO, etc., but you can imagine the resistance!<br></span></div>
<div>
<br><span></span>
</div>
<div><span>Frank on the other hand has very few optimizations -- it is about lines
 of code that carry meaning. It is a goal of the project to "separate optimizations from the meanings" so it would still run with the optimizations turned off but slower. We have done very little of this so far, and very few optimizations. We can give live dynamic demos in part because Dan Amelang's Nile graphics system turned out to be more efficient than we thought with very few optimizations.</span></div>
<div>
<br><span></span>
</div>
<div><span>I think it could be an valuable project for interested parties to see about how to organize the separate "optimization spaces" that use the meanings as references.</span></div>
<div>
<br><span></span>
</div>
<div><span>Cheers,</span></div>
<div>
<br><span></span>
</div>
<div><span>Alan<br></span></div>
<div>
<br><span></span>
</div>
<div><span></span></div>
<div>
<br><blockquote>  <div> <div> <div dir="ltr">  <span>From:</span> Jecel Assumpcao Jr. &lt;jecel@...&gt;<br><span>To:</span> Fundamentals of New Computing &lt;fonc@...&gt; <br><span>Sent:</span> Tuesday, February 7, 2012 9:42 AM<br><span>Subject:</span> Re: [fonc] Raspberry Pi<br> </div> <br>
Reuben Thomas wrote:<br>&gt; On 7 February 2012 11:34, Ryan Mitchley wrote:<br>&gt; &gt;<br>&gt; &gt; I think the limited capabilities would be a great visceral demonstration of<br>&gt; &gt; the efficiencies learned during the FONC research.<br>&gt; &gt;<br>&gt; &gt; I was thinking in terms of replacing the GNU software, using it as a cheap<br>&gt; &gt; hardware target... some FONC-based system should blow the GNU stack out of<br>&gt; &gt; the water when resources are restricted.<br>&gt; <br>&gt; Now that's an exciting idea.<br><br>People complain about *only* having 256MB (128MB in the A model) but<br>that is way more than is needed for SqueakNOS and, I imagine, Frank.<br>Certainly the boot time for SqueakNOS would be a second or less on this<br>hardware, which should impress a few people when compared to the various<br>Linux on the same board.<br><br>Fortunately, some information needed to port an OS to the Raspberry Pi<br>was released
 yesterday:<br><br>&gt; http://dmkenr5gtnd8f.cloudfront.net/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf<br><br>The GPU stuff is still secret but I don't think the current version of<br>Frank would make use of it anyway.<br><br>-- Jecel<br><br>_______________________________________________<br>fonc mailing list<br><a ymailto="mailto:fonc@..." href="mailto:fonc@...">fonc@...</a><br>http://vpri.org/mailman/listinfo/fonc<br><br><br>
</div> </div> </blockquote>
</div>   </div></div>
Hans-Martin Mosner | 7 Feb 19:51 2012
Picon

Re: Raspberry Pi

Am 07.02.2012 18:19, schrieb Alan Kay:
> Hi Jecel
>
> In the "difference between research and engineering department" I think I would first port a version of
Smalltalk to this system. 
Squeak and Scratch already run on it, can be loaded from the debian repositories.
The VM is not Cog, but maybe an ARM code generator for Cog could be a nice addition :-)

Apart from that, I too think that the Raspberry Pi will be a nice platform for experimentation and learning, especially
since the complete operating system and all other software is on exchangeable compact flash storage,
which could mean
that users could have separate SD cards for Scratch, Python, Frank, media center software, etc.

Cheers,
Hans-Martin
Reuben Thomas | 7 Feb 19:54 2012

Re: Raspberry Pi

On 7 February 2012 18:51, Hans-Martin Mosner <hmm@...> wrote:
>
> Apart from that, I too think that the Raspberry Pi will be a nice platform for experimentation and
learning, especially
> since the complete operating system and all other software is on exchangeable compact flash storage,
which could mean
> that users could have separate SD cards for Scratch, Python, Frank, media center software, etc.

I'm baffled as to how having separate storage for different components
helps. Could you explain? I'd've thought it would be easier to use if
they were all available at the same time.

(A similar point was made earlier in the thread about OS
experimentation; again, how is that better than using VMs?)

--

-- 
http://rrt.sc3d.org
Hans-Martin Mosner | 7 Feb 20:21 2012
Picon

Re: Raspberry Pi

Am 07.02.2012 19:54, schrieb Reuben Thomas:
> On 7 February 2012 18:51, Hans-Martin Mosner <hmm@...> wrote:
>> Apart from that, I too think that the Raspberry Pi will be a nice platform for experimentation and
learning, especially
>> since the complete operating system and all other software is on exchangeable compact flash storage,
which could mean
>> that users could have separate SD cards for Scratch, Python, Frank, media center software, etc.
> I'm baffled as to how having separate storage for different components
> helps. Could you explain? I'd've thought it would be easier to use if
> they were all available at the same time.
>
> (A similar point was made earlier in the thread about OS
> experimentation; again, how is that better than using VMs?)
>
VMs are of course more versatile, but the little ARM SoC will probably not support VMs too well. In addition,
there is a
certain "geek" quality in knowing that your OS is running on the "bare metal" and not inside some emulator :-)
The reason I hope that separate media encourages experimentation is that you're much less likely to brick
your device,
either by your own actions or by some innocently-looking upgrade. I know that on my Ubuntu desktop, I've
been bitten by
incompatible OS upgrades several times, which meant that I had to revisit software that was working
perfectly well
before such an upgrade just to make it runnable again.
Whether it really work out that way remains to be seen - I am not totally sure that it will, but I see it as a possibility.
In any case, you could attach an USB disk with a conventional OS install and have everything together. This
might even
be the preferred mode of operation if you switch between media playing, internet and programming.
Jecel Assumpcao Jr. | 8 Feb 03:20 2012

Re: Raspberry Pi

Alan Kay wrote:
> In the "difference between research and engineering department" I
> think I would first port a version of Smalltalk to this system. 

The Squeak VM used in the new OLPC machine should work just fine on this
board on top of one of the Linuxes that have already been tested on it.
It probably will be half the speed of the OLPC XO 1.75, but I expect it
to be very usable.

> One of the fun side-projects done in the early part of the Squeak
> system was when John Maloney and a Berkeley grad student ported
> Squeak to "a luggage tag" -- that is to the Mitsubishi hybrid "computer
> on a chip" that existed back ca 1997. This was a ARM-like 32 bit
> microprocessor plus 4MB (or more) memory on a single die. This plus
> one ASIC constituted the whole computer. 

I had meant to mention this project in my previous post. It was briefly
mentioned in these pages:

http://wiki.squeak.org/squeak/5727
http://sib-download.ddo.jp/~sib/Squeak_World/Squeak_Swiki/271.html (this
link didn't work for me today)

A similar effort used the Hyperstone chip:

http://wiki.squeak.org/squeak/1836

> Mitsubishi did this nice system for mobile use. Motorola bought the
> rights to this technology and completely buried it to kill competition.

Actually, a company called Renesas sold this chip for many years. But I
have just checked and their version lacks the large embedded DRAM and
only has the typical memory of a high end microcontroller:

http://www.renesas.com/products/mpumcu/m32r/index.jsp

> (We call it the "luggage tag" because they would embed failed chips
> in Lucite to make luggage tags!)

Cute! I was interested in doing something like this with working chips
to have a part children could use to build their own computers, even if
they dropped it on the floor and the dog chewed on it a bit. By having
the bare chip visible (even if not very clearly), it would seem a little
less mysterious than normal electronics.

> Anyway, for fun John and the grad student ported Squeak to this bare chip
> (including having to write the BiOS code). It worked fine, and I was able to
> do a large scale Etoy demo on it.
> Although Squeak was quite small in those days, a number of effective
> optimizations had been done at various levels, and so it was quite efficient,
> and all plus Etoys fit easily into 4MB. 

The Squeak that David Ungar and friends are running on the Tile64 chips
uses a 2MB image in order to fit entirely in that chip's level 2 cache
so that they don't have to deal with access to the external memory.

> In the earliest days of the OLPC XO project we made an offer to make Squeak
> the entire OS of the XO, etc., but you can imagine the resistance!

I only learned about this in 2009. Back in 2005 I tried to form a group
on the squeak-dev list to put Squeak on that machine. Nobody showed any
interest, so I wrote offering to collaborate but was told that they
didn't need my help because you and your team were already working on
it.

At the time the argument about the relative size of the Python and
Squeak communities made perfect sense. And L. Peter Deutsch was then
working on a real VM for what had become his favorite language:

http://marginalguesswork.blogspot.com/2004/08/you-dont-tug-on-supermans-
cape.html

In retrospect, I feel it was a mistake. Everyone who is coding in Python
for OLPC and Sugar learned the language for that project. The Python
community is mostly unaware of these projects and have not helped in any
way that I have seen. If the money and effort spent on Sugar had been
spent on cleaning up SqueakNOS and Morphic/Etoys instead I think the
result might have been more interesting. But all the technical people
were Unix guys and Red Hat and AMD were paying, so there was no real
chance of the project being done other than how it was.

> Frank on the other hand has very few optimizations -- it is about lines of code
> that carry meaning. It is a goal of the project to "separate optimizations from
> the meanings" so it would still run with the optimizations turned off but slower.

I liked so much that I have adopted it as a goal for my PhD project. I
will attempt a different path than VPRI (partial evaluation of nested
interpreters instead of a chain of compilers) so we can better explore
the territory.

> We have done very little of this so far, and very few optimizations. We can give
> live dynamic demos in part because Dan Amelang's Nile graphics system turned
> out to be more efficient than we thought with very few optimizations.

Here is were the binary blob thing in the Raspberry Pi would be a
problem. A Nile backend for the board's GPU can't be written, and the
CPU can't compare to the PCs you use in your demos.

> I think it could be an valuable project for interested parties to see about how to
> organize the separate "optimization spaces" that use the meanings as references.

I didn't get the part about "meanings as references".

Reuben Thomas asked:
> I'm baffled as to how having separate storage for different components
> helps. Could you explain? I'd've thought it would be easier to use if
> they were all available at the same time.

Hans-Martin Mosner replied:
> The reason I hope that separate media encourages experimentation is that you're
> much less likely to brick your device, either by your own actions or by some
> innocently-looking upgrade. I know that on my Ubuntu desktop, I've been bitten by
> incompatible OS upgrades several times, which meant that I had to revisit software
> that was working perfectly well before such an upgrade just to make it runnable again.

That is a very good point, but the reason why I have tried to design my
computers with 100% removable media is so they can be shared in a
classroom. Even at $35 a class might not have one per student. If you
have 10 machines and 30 students, each with their own SD card, it works
better than if you have permanent stuff inside each computer. Though
today's users have learned to cope with hard disks and installing
software, the old floppy-only machines were actually easier for them.
This worked pretty well for the Alto:

http://www.computerhistory.org/revolution/input-output/14/347/1858

-- Jecel

Loup Vaillant | 8 Feb 10:29 2012
Picon

Re: Raspberry Pi

Jecel Assumpcao Jr. wrote:
> Alan Kay wrote:
>> We have done very little of this so far, and very few optimizations. We can give
>> live dynamic demos in part because Dan Amelang's Nile graphics system turned
>> out to be more efficient than we thought with very few optimizations.
>
> Here is were the binary blob thing in the Raspberry Pi would be a
> problem. A Nile backend for the board's GPU can't be written, and the
> CPU can't compare to the PCs you use in your demos.

Maybe as a temporary workaround, it would possible to use OpenGL (or
OpenCL, if available) as the back-end?  It would require loading a
whole Linux kernel, but maybe this could work? </wild_speculation>

>> I think it could be an valuable project for interested parties to see about how to
>> organize the separate "optimization spaces" that use the meanings as references.
>
> I didn't get the part about "meanings as references".

I understood that "meanings" meant "the concise version of Frank".  The
"optimization space" would then be a set of correctness-preserving
compilers passes or interpreters. (I believe Frank already features
some of that.)

Or, re-written versions that are somehow guaranteed to behave the same
as the concise version they derive from, only faster.  But I'm not sure
that's the spirit.

Loup.
Alan Kay | 8 Feb 16:23 2012
Picon

Re: Raspberry Pi

Hi Loup

Actually, your last guess was how we thought most of the optimizations would be done (as separate code "guarded" by the meanings). For example, one idea was that Cairo could be the optimizations of the "graphics meanings code" we would come up with. But Dan Amelang did such a great job at the meanings that they ran fast enough tempt us to use them directly (rather than on a supercomputer, etc.). In practice, the optimizations we did do are done in the translation chain and in the run-time, and Cairo never entered the picture.

However, this is a great area for developing more technique for how "math" can be made practical -- because the model is so "pretty" and "compact" -- and there is much more that could be done here.

Why can't a Nile backend for the GPU board be written? Did I miss something?

Cheers,

Alan


From: Loup Vaillant <l <at> loup-vaillant.fr>
To: fonc-uVco7kAcSAQ@public.gmane.org
Sent: Wednesday, February 8, 2012 1:29 AM
Subject: Re: [fonc] Raspberry Pi

Jecel Assumpcao Jr. wrote:
> Alan Kay wrote:
>> We have done very little of this so far, and very few optimizations. We can give
>> live dynamic demos in part because Dan Amelang's Nile graphics system turned
>> out to be more efficient than we thought with very few optimizations.
>
> Here is were the binary blob thing in the Raspberry Pi would be a
> problem. A Nile backend for the board's GPU can't be written, and the
> CPU can't compare to the PCs you use in your demos.

Maybe as a temporary workaround, it would possible to use OpenGL (or
OpenCL, if available) as the back-end?  It would require loading a
whole Linux kernel, but maybe this could work? </wild_speculation>


>> I think it could be an valuable project for interested parties to see about how to
>> organize the separate "optimization spaces" that use the meanings as references.
>
> I didn't get the part about "meanings as references".

I understood that "meanings" meant "the concise version of Frank".  The
"optimization space" would then be a set of correctness-preserving
compilers passes or interpreters. (I believe Frank already features
some of that.)

Or, re-written versions that are somehow guaranteed to behave the same
as the concise version they derive from, only faster.  But I'm not sure
that's the spirit.

Loup.
_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


<div><div>
<div><span>Hi Loup</span></div>
<div>
<br><span></span>
</div>
<div><span>Actually, your last guess was how we thought most of the optimizations would be done (as separate code "guarded" by the meanings). For example, one idea was that Cairo could be the optimizations of the "graphics meanings code" we would come up with. But Dan Amelang did such a great job at the meanings that they ran fast enough tempt us to use them directly (rather than on a supercomputer, etc.). In practice, the optimizations we did do are done in the translation chain and in the run-time, and Cairo never entered the picture.<br></span></div>
<div><br></div>
<div>However, this is a great area for developing more technique for how "math" can be made practical -- because the model is so "pretty" and "compact" -- and there is much more that could be done
 here.</div>
<div><br></div>
<div>Why can't a Nile backend for the GPU board be written? Did I miss something?</div>
<div><br></div>
<div>Cheers,</div>
<div><br></div>
<div>Alan<br>
</div>
<div><br></div>
<div>
<br><blockquote>  <div> <div> <div dir="ltr">  <span>From:</span> Loup Vaillant &lt;l <at> loup-vaillant.fr&gt;<br><span>To:</span> fonc@... <br><span>Sent:</span> Wednesday, February 8, 2012 1:29 AM<br><span>Subject:</span> Re: [fonc] Raspberry Pi<br> </div> <br>
Jecel Assumpcao Jr. wrote:<br>&gt; Alan Kay wrote:<br>&gt;&gt; We have done very little of this so far, and very few optimizations. We can give<br>&gt;&gt; live dynamic demos in part because Dan Amelang's Nile graphics system turned<br>&gt;&gt; out to be more efficient than we thought with very few optimizations.<br>&gt;<br>&gt; Here is were the binary blob thing in the Raspberry Pi would be a<br>&gt; problem. A Nile backend for the board's GPU can't be written, and the<br>&gt; CPU can't compare to the PCs you use in your demos.<br><br>Maybe as a temporary workaround, it would possible to use OpenGL (or<br>OpenCL, if available) as the back-end?&nbsp; It would require loading a<br>whole Linux kernel, but maybe this could work? &lt;/wild_speculation&gt;<br><br><br>&gt;&gt; I think it could be an valuable project for interested parties to see about how to<br>&gt;&gt; organize the separate "optimization spaces" that use the meanings as
 references.<br>&gt;<br>&gt; I didn't get the part about "meanings as references".<br><br>I understood that "meanings" meant "the concise version of Frank".&nbsp; The<br>"optimization space" would then be a set of correctness-preserving<br>compilers passes or interpreters. (I believe Frank already features<br>some of that.)<br><br>Or, re-written versions that are somehow guaranteed to behave the same<br>as the concise version they derive from, only faster.&nbsp; But I'm not sure<br>that's the spirit.<br><br>Loup.<br>_______________________________________________<br>fonc mailing list<br><a ymailto="mailto:fonc@..." href="mailto:fonc@...">fonc@...</a><br>http://vpri.org/mailman/listinfo/fonc<br><br><br>
</div> </div> </blockquote>
</div>   </div></div>
Reuben Thomas | 8 Feb 16:37 2012

Re: Raspberry Pi

On 8 February 2012 15:23, Alan Kay <alan.nemo@...> wrote:
> Hi Loup
>
> Why can't a Nile backend for the GPU board be written? Did I miss something?

You can't drive it directly because its specs aren't public. If you
use its closed-source Linux driver, you can of course use OpenGL.

--

-- 
http://rrt.sc3d.org
Tony Garnock-Jones | 8 Feb 23:04 2012
Picon

Re: Raspberry Pi

On 8 February 2012 10:37, Reuben Thomas <rrt-0NV8xZLkR+A@public.gmane.org> wrote:
You can't drive it directly because its specs aren't public. If you
use its closed-source Linux driver, you can of course use OpenGL.

The list might be interested in recent developments on another mailing list I follow, http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook, a list for discussing a completely free-software-compatible modular hardware design. In particular, I'm thinking of this recent message http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-February/002278.html in which the project's leader Luke Leighton writes about the possibility of building a SoC including such features as...

<blockquote>
[...] create a new (entirely software-based) SoC that would be entirely FSF-Endorseable as it would be entirely software-programmable. [...]

the company that i've found that has an alternative 32-bit RISC core not only has SMP cache coherency already done, but also they have an absolutely amazing set of Instruction extensions, including DSP, Audio, Video, Base-band (for RF handset processing) and much more. the plan is, therefore, to target this CPU at a very very wide range of markets, based on it having:

* 8 CPUs at 1.2ghz or above
* SMP Cache Coherency
* 32-bit DDR3 1333mhz RAM (with a 2nd version having 2 DDR3 interfaces)
* virtually everything software-programmable (with the exception of
CABAC decode)

meaning that it will do 3D graphics _and_ 1080p Video entirely in
software. the interfaces i've selected so far will include:

* HDMI Out _and_ In
* 24-pin RGB/TTL
* 2-channel LVDS
* 2 PCIe (2-lane each)
* USB-OTG, USB-2 and USB-3
* SATA-3
* NAND controller (8-bit with 4-way CS)
* 3 SD/MMC interfaces
* 3 SPI interfaces
* 3 UARTs, 3 IIC interfaces, CAN-Bus, 2 PS/2, Touchscreen, 3 PWMs
* 2 MPEG Transport Stream Interfaces
* Smartcard Interface

that means that it could be used in at least the following products:

* Laptops, Netbooks, Tablets, Desktops, PCs, NAS-Boxes
* PVRs, TVs, Set-Top Boxes, Satellite Decoders
* Smartphones, Base Stations, GNU/Radio SDR Products

bearing in mind that this will be out some time in middle of 2013, if
it's started soon, i could reallly do with some help reviewing the
interfaces and capabilities, to make sure i've got it right.

</blockquote>

If anyone here is interested in the possible intersection of Frank with this hardware project, please do get in touch with Luke, either directly or via the list.

Jecel, perhaps you could critique the idea, given your experience with alternative (for want of a better term) architectures?

Regards,
  Tony
--
Tony Garnock-Jones
tonygarnockjones-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
http://homepages.kcbbs.gen.nz/tonyg/
<div>
<div class="gmail_quote">On 8 February 2012 10:37, Reuben Thomas <span dir="ltr">&lt;<a href="mailto:rrt@...">rrt@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
You can't drive it directly because its specs aren't public. If you<br>
use its closed-source Linux driver, you can of course use OpenGL.<br>
</blockquote>
<div>
<br>The list might be interested in recent developments on another mailing 
list I follow, <a href="http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook">http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook</a>, a
 list for discussing a completely free-software-compatible modular hardware design.
 In particular, I'm thinking of this recent message 
<a href="http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-February/002278.html">http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-February/002278.html</a>
 in which the project's leader Luke Leighton writes about the 
possibility of building a SoC including such features as...<br><br>&lt;blockquote&gt;<br><blockquote>[...]
 create a new (entirely software-based) SoC that would be entirely 
FSF-Endorseable as it would be entirely software-programmable. [...]<br><br>
 the company that i've found that has an alternative 32-bit RISC core 
not only has SMP cache coherency already done, but also they have an 
absolutely amazing set of Instruction extensions, including DSP, Audio, 
Video, Base-band (for RF handset processing) and much more. the plan is,
 therefore, to target this CPU at a very very wide range of markets, 
based on it having:<br><br>* 8 CPUs at 1.2ghz or above<br>* SMP Cache Coherency<br>* 32-bit DDR3 1333mhz RAM (with a 2nd version having 2 DDR3 interfaces)<br>* virtually everything software-programmable (with the exception of<br>
CABAC decode)<br><br>meaning that it will do 3D graphics _and_ 1080p Video entirely in<br>software.  the interfaces i've selected so far will include:<br><br>* HDMI Out _and_ In<br>* 24-pin RGB/TTL<br>* 2-channel LVDS<br>
* 2 PCIe (2-lane each)<br>* USB-OTG, USB-2 and USB-3<br>* SATA-3<br>* NAND controller (8-bit with 4-way CS)<br>* 3 SD/MMC interfaces<br>* 3 SPI interfaces<br>* 3 UARTs, 3 IIC interfaces, CAN-Bus, 2 PS/2, Touchscreen, 3 PWMs<br>
* 2 MPEG Transport Stream Interfaces<br>* Smartcard Interface<br><br>that means that it could be used in at least the following products:<br><br>* Laptops, Netbooks, Tablets, Desktops, PCs, NAS-Boxes<br>* PVRs, TVs, Set-Top Boxes, Satellite Decoders<br>
* Smartphones, Base Stations, GNU/Radio SDR Products<br><br>bearing in mind that this will be out some time in middle of 2013, if<br>it's started soon, i could reallly do with some help reviewing the<br>interfaces and capabilities, to make sure i've got it right.<br><br>
</blockquote>&lt;/blockquote&gt;<br><br>
If anyone here is interested in the possible intersection of Frank with 
this hardware project, please do get in touch with Luke, either directly
 or via the list.<br><br>
Jecel, perhaps you could critique the idea, given your experience with alternative (for want of a better term) architectures?<br><br>
Regards,<br>
&nbsp; Tony<br>
</div>
</div>-- <br>Tony Garnock-Jones<br><a href="mailto:tonygarnockjones@..." target="_blank">tonygarnockjones@...</a><br><a href="http://homepages.kcbbs.gen.nz/tonyg/" target="_blank">http://homepages.kcbbs.gen.nz/tonyg/</a><br>
</div>
Tony Garnock-Jones | 8 Feb 23:06 2012
Picon

Re: Raspberry Pi

On 8 February 2012 10:37, Reuben Thomas <rrt-0NV8xZLkR+A@public.gmane.org> wrote:

You can't drive it directly because its specs aren't public. If you
use its closed-source Linux driver, you can of course use OpenGL.

Uh, and I should also point out the promising work on an open-source GPU driver: "... an open-source, reverse-engineered graphics driver for the ARM Mali graphics processor. OpenGL ES triangles are in action on open-source code." via http://www.phoronix.com/scan.php?page=article&item=arm_mali_reverse&num=1

Regards,
  Tony
--
Tony Garnock-Jones
tonygarnockjones <at> gmail.com
http://homepages.kcbbs.gen.nz/tonyg/
<div>
<p>On 8 February 2012 10:37, Reuben Thomas <span dir="ltr">&lt;<a href="mailto:rrt@...">rrt@...</a>&gt;</span> wrote:<br></p>
<div class="gmail_quote">
<blockquote class="gmail_quote">

You can't drive it directly because its specs aren't public. If you<br>
use its closed-source Linux driver, you can of course use OpenGL.<br>
</blockquote>
<div>
<br>Uh, and I should also point out the promising work on an open-source GPU driver: "... an open-source, 
reverse-engineered graphics driver for the ARM Mali graphics processor. OpenGL 
ES triangles are in action on open-source code." via <a href="http://www.phoronix.com/scan.php?page=article&amp;item=arm_mali_reverse&amp;num=1">http://www.phoronix.com/scan.php?page=article&amp;item=arm_mali_reverse&amp;num=1</a><br><br>Regards,<br>&nbsp; Tony<br>
</div>
</div>-- <br>Tony Garnock-Jones<br><a href="mailto:tonygarnockjones@..." target="_blank">tonygarnockjones <at> gmail.com</a><br><a href="http://homepages.kcbbs.gen.nz/tonyg/" target="_blank">http://homepages.kcbbs.gen.nz/tonyg/</a><br>
</div>
Jecel Assumpcao Jr. | 8 Feb 18:39 2012

Re: Raspberry Pi

Alan,

> Hi Loup
> Actually, your last guess was how we thought most of the optimizations would
> be done (as separate code "guarded" by the meanings). For example, one idea
> was that Cairo could be the optimizations of the "graphics meanings code" we
> would come up with. But Dan Amelang did such a great job at the meanings that
> they ran fast enough tempt us to use them directly (rather than on a supercomputer,
> etc.). In practice, the optimizations we did do are done in the translation chain and
> in the run-time, and Cairo never entered the picture.
> 
> However, this is a great area for developing more technique for how "math" can
> be made practical -- because the model is so "pretty" and "compact" -- and there
> is much more that could be done here.

Here is an old idea I had for a "cache manager" (as described in
http://www.merlintec.com/lsi/tech.html):

One feature that distinguishes programs by experts from those of novices
is the use of caching as a performance enhancement. Saving results for
later reuse greatly decreases source code readability, unfortunately,
obscuring program logic and making debugging much harder. Reflection
allows us to move caching to a separate implementation layer in a cache
manager object. So the application can be written and debugged "naively"
and, after it works, can be annotated to use the cache manager at
critical points to significantly improve performance without having to
write a new version.

This is only possible because Merlin uses message passing "at the
bottom" and includes a reflective access to such a fundamental
operation. In other words, user applications are never made up of mainly
"big black boxes" which the OS can do nothing about. Even simple math
expressions as '(x * 2 ) + y' are entirely built from messages that are
(in theory - the compiler actually eliminates most of the overhead)
handled by a set of meta-objects. So all that the system has to do when
the user annotates an expression as cacheable is to replace the standard
send meta-object with one that looks up its arguments in a table (cache)
and returns a previously calculated answer if it is found there.
Otherwise it works exactly like a normal send meta-object.

An example of how this works is in rendering text. A given font's glyphs
might be given as sets of control points for Bezier curves describing
their outlines plus some "hints" for adjusting these points when
scaling. We could then draw a character from a font called myFont on
aCanvas with the expression:

   aCanvas drawPixmap: ((myFont glyphFor: 'a' Size: 12)

                                asVectors asPixmap)

This should work perfectly, but will be unacceptably slow. For each time
some character must be shown in the display its points must be scaled by
the 'glyphFor:Size:' method, then the control points must be rendered as
short vectors approximating the indicated Bezier curves ('asVectors')
and finally these vectors must be used to fill in a picture ('asPixmap')
which can finally simply be blasted on the screen for the final result.
By marking each of these messages as cacheable, the next time
'glyphFor:Size:' is sent to myFont with exactly 'a' and 12 as arguments
it will return the same list of control points without executing the
method again. Sending a cacheable 'asVectors' message to the same list
of point as before will fetch the same list of vectors as was created
the first time, and sending 'asPixmap' to that results in the same
character image without actually invoking the filling method once more.
So we have replaced three very complex and slow calculations with three
simple table lookups. If you think that even that is too much, you are
right. The cached control point lists and short vector lists are not
really needed. Unfortunately, the cache manager can do nothing about
that, but if the user moves multiply cached expression to their own
methods like this:

  pixmapForFont: f Char: c Size: s =  ( (f glyphFor: c Size: s)

                                          asVectors asPixmap).

   ....

   aCanvas drawPixmap: (pixmapForFont: myFont Char: 'a' Size: 12)

Now we can make only the 'pixmapForFont:Char:Size:' method cacheable if
we want. This will save the final pixmaps without also storing the
intermediate (and useless to us) results. This did involve rewriting
application code, but actually made it a little more readable, unlike
when caching is "hand coded".

> Why can't a Nile backend for the GPU board be written? Did I miss something?

As Reuben Thomas pointed it, the needed information is not available. In
fact, there was no information at all about the chip until this week,
but now we have some 30% (the most important part for porting the basic
funcionality of some OS). This is the same issue that the OLPC people
had (worse in their case, because people would promise to release the
information to get them to use a chip and then just didn't do it). Even
dealing with FPGA is a pain because of the secret parts.

-- Jecel

Loup Vaillant | 8 Feb 18:24 2012
Picon

Re: Raspberry Pi

Alan Kay wrote:
> Hi Loup
>
> Actually, your last guess was how we thought most of the optimizations
> would be done (as separate code "guarded" by the meanings).  […]
 > In practice, the  optimizations we did do are done in the translation
 > chain and in the run-time, […]

Okay, thanks.

I can't recall the exact reference, but I have read once about a middle
ground: mechanical optimization passes that are brittle in the face of
meaning change.  I mean, if you change the concise version of your
program, you may have to re-think your optimizations passes, but you
don't necessarily have to re-write your optimized version directly.

Example
{
   The guy where at the university, and was assigned to write optimized
   multiplication for big numbers.  Each student would  be graded
   according to the speed of their program.  No restriction on the
   programming language.

   Everyone started coding in C, but _he_ preferred to start with
   scheme.  He coded a straightforward version of the algorithm, then
   set out to manually (but mostly mechanically) apply a set of
   correctness-preserving transformations, most notably a CPS
   transformation, and a direct translation to C with gotos.  His final
   program, written in pure C, was the second fastest of his class (and
   very close to the first, which used assembly heavily).  Looking back
   at what he could have done better, he saw that his program spent most
   of his time in malloc().  He didn't know how to do it at the time,
   but he had managed his memory directly, his program would have been
   first.

   Oh, and of course, he had much less trouble dealing with mistakes
   than his classmates.

   So, his conclusion was that speed comes from beautiful programs, not
   "prematurely optimized" ones.
}

About Frank, we may imagine using this method in a more automated way,
for instance by annotating the source and intermediate code with
specialized optimizations that would only work in certain cases.  It
could be something roughly like this:

Nile Source            <- Annotations to optimize the Nile program
    |
    |                      Compiler pass that check the validity of the
    |                      optimizations then applies them.
    v
Maru Intermediate code <- Annotations to optimize that maru program
    |
    |                      Compiler pass like the above
    v
C Backend code         <- Annotations (though at this point…)
    |
    |                   <- GCC
    v
Assembly               <- (no, I won't touch that :-)

(Note that instead of annotating the programs, you could manually
  control the compilers.)

Of course, the second you change the Nile source is the second your
annotations at every level won't work any more.  But (i) you would only
have to redo your annotations, and (ii), maybe not all of them anyway,
for there is a slight chance that your intermediate representation
didn't change too much when you changed your source code.

I can think of one big caveat however: if the generated code is too big
or too cryptic, this approach may not be feasible any more.  And I
forgot about profiling your program first.

 > But Dan Amelang did such a great job at the meanings that they ran
 > fast enough tempt us to use them directly [so] Cairo never entered
 > the picture.

If I had to speculate from an outsider's point of view, I'd say these
good surprises probably apply to almost any domain specific language.
The more specialized a language is, the more domain knowledge you can
embed in the compiler, the more efficient the optimizations may be. I
know it sounds like magic, but I recall a similar example with Haskell,
applied to bioinformatics (again, can't find the paper).

Example
{
   The goal was to implement a super-fast algorithm.  The catch was, the
   resulting program has to accept a rather big number of parameters.
   Written directly in C, the fact that those parameters changed meant
   the main loop had to make several checks, slowing the whole thing
   down.

   So they did an EDSL based on monads that basically generated a C
   program after the parameters were read and knows, then ran it.  Not
   quite Just-In-Time compilation, but close.  The result was of course
   noticeably faster than the original C program.
}

Therefore, I'm quite optimistic.  My best guess right now is that smart
compilers will be more than enough to make Frank "fast enough", "as fast
as C"[1] or possibly even faster, for 2 reasons:

1. As far as I know, most languages in Frank are quite specialized.
    That prior knowledge can be exploited by compilers.
2. The code volume is sufficiently small that aggressive whole program
    optimizations are actually feasible.

Such compilers may cost 10 to 100 thousands lines or more, but at least
those lines would be strictly contained. Then, potential end users
wouldn't give up too much hackability in the name of performance.

[1]: http://c2.com/cgi/wiki?AsFastAsCee

Loup.
_______________________________________________
fonc mailing list
fonc <at> vpri.org
http://vpri.org/mailman/listinfo/fonc
Alan Kay | 8 Feb 18:46 2012
Picon

Re: Raspberry Pi

Yes, the "annotation" scheme you mention is essentially how were were going to do it. The idea was that in the optimization space there would be a variety of ways to do X -- e.g. there are lots of ways to do sorting -- and there would be conditions attached to these ways that would allow the system to choose the most appropriate solutions at the most appropriate times. This would include "hints" etc. The rule here is that the system had to be able to run correctly with all the optimizations turned off.

And your notions about some of the merits of DSLs (known in the 60s as POLs -- for Problem Oriented Languages) is why we took this approach.

Cheers,

Alan

From: Loup Vaillant <l <at> loup-vaillant.fr>
To: fonc <at> vpri.org
Sent: Wednesday, February 8, 2012 9:24 AM
Subject: Re: [fonc] Raspberry Pi

Alan Kay wrote:
> Hi Loup
>
> Actually, your last guess was how we thought most of the optimizations
> would be done (as separate code "guarded" by the meanings).  […]
> In practice, the  optimizations we did do are done in the translation
> chain and in the run-time, […]


Okay, thanks.

I can't recall the exact reference, but I have read once about a middle
ground: mechanical optimization passes that are brittle in the face of
meaning change.  I mean, if you change the concise version of your
program, you may have to re-think your optimizations passes, but you
don't necessarily have to re-write your optimized version directly.

Example
{
  The guy where at the university, and was assigned to write optimized
  multiplication for big numbers.  Each student would  be graded
  according to the speed of their program.  No restriction on the
  programming language.

  Everyone started coding in C, but _he_ preferred to start with
  scheme.  He coded a straightforward version of the algorithm, then
  set out to manually (but mostly mechanically) apply a set of
  correctness-preserving transformations, most notably a CPS
  transformation, and a direct translation to C with gotos.  His final
  program, written in pure C, was the second fastest of his class (and
  very close to the first, which used assembly heavily).  Looking back
  at what he could have done better, he saw that his program spent most
  of his time in malloc().  He didn't know how to do it at the time,
  but he had managed his memory directly, his program would have been
  first.

  Oh, and of course, he had much less trouble dealing with mistakes
  than his classmates.

  So, his conclusion was that speed comes from beautiful programs, not
  "prematurely optimized" ones.
}


About Frank, we may imagine using this method in a more automated way,
for instance by annotating the source and intermediate code with
specialized optimizations that would only work in certain cases.  It
could be something roughly like this:

Nile Source            <- Annotations to optimize the Nile program
  |
  |                      Compiler pass that check the validity of the
  |                      optimizations then applies them.
  v
Maru Intermediate code <- Annotations to optimize that maru program
  |
  |                      Compiler pass like the above
  v
C Backend code        <- Annotations (though at this point…)
  |
  |                  <- GCC
  v
Assembly              <- (no, I won't touch that :-)

(Note that instead of annotating the programs, you could manually
control the compilers.)

Of course, the second you change the Nile source is the second your
annotations at every level won't work any more.  But (i) you would only
have to redo your annotations, and (ii), maybe not all of them anyway,
for there is a slight chance that your intermediate representation
didn't change too much when you changed your source code.

I can think of one big caveat however: if the generated code is too big
or too cryptic, this approach may not be feasible any more.  And I
forgot about profiling your program first.



> But Dan Amelang did such a great job at the meanings that they ran
> fast enough tempt us to use them directly [so] Cairo never entered
> the picture.

If I had to speculate from an outsider's point of view, I'd say these
good surprises probably apply to almost any domain specific language.
The more specialized a language is, the more domain knowledge you can
embed in the compiler, the more efficient the optimizations may be. I
know it sounds like magic, but I recall a similar example with Haskell,
applied to bioinformatics (again, can't find the paper).

Example
{
  The goal was to implement a super-fast algorithm.  The catch was, the
  resulting program has to accept a rather big number of parameters.
  Written directly in C, the fact that those parameters changed meant
  the main loop had to make several checks, slowing the whole thing
  down.

  So they did an EDSL based on monads that basically generated a C
  program after the parameters were read and knows, then ran it.  Not
  quite Just-In-Time compilation, but close.  The result was of course
  noticeably faster than the original C program.
}

Therefore, I'm quite optimistic.  My best guess right now is that smart
compilers will be more than enough to make Frank "fast enough", "as fast
as C"[1] or possibly even faster, for 2 reasons:

1. As far as I know, most languages in Frank are quite specialized.
  That prior knowledge can be exploited by compilers.
2. The code volume is sufficiently small that aggressive whole program
  optimizations are actually feasible.

Such compilers may cost 10 to 100 thousands lines or more, but at least
those lines would be strictly contained. Then, potential end users
wouldn't give up too much hackability in the name of performance.

[1]: http://c2.com/cgi/wiki?AsFastAsCee

Loup.
_______________________________________________
fonc mailing list
fonc-uVco7kAcSAQ@public.gmane.org
http://vpri.org/mailman/listinfo/fonc


<div><div>
<div><span>Yes, the "annotation" scheme you mention is essentially how were were going to do it. The idea was that in the optimization space there would be a variety of ways to do X -- e.g. there are lots of ways to do sorting -- and there would be conditions attached to these ways that would allow the system to choose the most appropriate solutions at the most appropriate times. This would include "hints" etc. The rule here is that the system had to be able to run correctly with all the optimizations turned off.</span></div>
<div>
<br><span></span>
</div>
<div><span>And your notions about some of the merits of DSLs (known in the 60s as POLs -- for Problem Oriented Languages) is why we took this
 approach.</span></div>
<div>
<br><span></span>
</div>
<div><span>Cheers,</span></div>
<div>
<br><span></span>
</div>
<div><span>Alan<br></span></div>
<div>
<br><blockquote>  <div> <div> <div dir="ltr">  <span>From:</span> Loup Vaillant &lt;l <at> loup-vaillant.fr&gt;<br><span>To:</span> fonc <at> vpri.org <br><span>Sent:</span> Wednesday, February 8, 2012 9:24 AM<br><span>Subject:</span> Re: [fonc] Raspberry Pi<br> </div> <br>
Alan Kay wrote:<br>&gt; Hi Loup<br>&gt; <br>&gt; Actually, your last guess was how we thought most of the optimizations<br>&gt; would be done (as separate code "guarded" by the meanings).&nbsp; [&hellip;]<br>&gt; In practice, the&nbsp; optimizations we did do are done in the translation<br>&gt; chain and in the run-time, [&hellip;]<br><br><br>Okay, thanks.<br><br>I can't recall the exact reference, but I have read once about a middle<br>ground: mechanical optimization passes that are brittle in the face of<br>meaning change.&nbsp; I mean, if you change the concise version of your<br>program, you may have to re-think your optimizations passes, but you<br>don't necessarily have to re-write your optimized version directly.<br><br>Example<br>{<br>&nbsp; The guy where at the university, and was assigned to write optimized<br>&nbsp; multiplication for big numbers.&nbsp; Each student would&nbsp; be graded<br>&nbsp; according to the speed of their program.&nbsp; No
 restriction on the<br>&nbsp; programming language.<br><br>&nbsp; Everyone started coding in C, but _he_ preferred to start with<br>&nbsp; scheme.&nbsp; He coded a straightforward version of the algorithm, then<br>&nbsp; set out to manually (but mostly mechanically) apply a set of<br>&nbsp; correctness-preserving transformations, most notably a CPS<br>&nbsp; transformation, and a direct translation to C with gotos.&nbsp; His final<br>&nbsp; program, written in pure C, was the second fastest of his class (and<br>&nbsp; very close to the first, which used assembly heavily).&nbsp; Looking back<br>&nbsp; at what he could have done better, he saw that his program spent most<br>&nbsp; of his time in malloc().&nbsp; He didn't know how to do it at the time,<br>&nbsp; but he had managed his memory directly, his program would have been<br>&nbsp; first.<br><br>&nbsp; Oh, and of course, he had much less trouble dealing with mistakes<br>&nbsp; than his
 classmates.<br><br>&nbsp; So, his conclusion was that speed comes from beautiful programs, not<br>&nbsp; "prematurely optimized" ones.<br>}<br><br><br>About Frank, we may imagine using this method in a more automated way,<br>for instance by annotating the source and intermediate code with<br>specialized optimizations that would only work in certain cases.&nbsp; It<br>could be something roughly like this:<br><br>Nile Source&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;- Annotations to optimize the Nile program<br>&nbsp;  |<br>&nbsp;  |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Compiler pass that check the validity of the<br>&nbsp;  |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; optimizations then applies them.<br>&nbsp;  v<br>Maru Intermediate code &lt;- Annotations to optimize that maru program<br>&nbsp;  |<br>&nbsp;  |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
 &nbsp; Compiler pass like the above<br>&nbsp;  v<br>C Backend code&nbsp; &nbsp; &nbsp; &nbsp;  &lt;- Annotations (though at this point&hellip;)<br>&nbsp;  |<br>&nbsp;  |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  &lt;- GCC<br>&nbsp;  v<br>Assembly&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;  &lt;- (no, I won't touch that :-)<br><br>(Note that instead of annotating the programs, you could manually<br> control the compilers.)<br><br>Of course, the second you change the Nile source is the second your<br>annotations at every level won't work any more.&nbsp; But (i) you would only<br>have to redo your annotations, and (ii), maybe not all of them anyway,<br>for there is a slight chance that your intermediate representation<br>didn't change too much when you changed your source code.<br><br>I can think of one big caveat however: if the generated code is too big<br>or too cryptic, this approach may not be feasible any more.&nbsp; And
 I<br>forgot about profiling your program first.<br><br><br><br>&gt; But Dan Amelang did such a great job at the meanings that they ran<br>&gt; fast enough tempt us to use them directly [so] Cairo never entered<br>&gt; the picture.<br><br>If I had to speculate from an outsider's point of view, I'd say these<br>good surprises probably apply to almost any domain specific language.<br>The more specialized a language is, the more domain knowledge you can<br>embed in the compiler, the more efficient the optimizations may be. I<br>know it sounds like magic, but I recall a similar example with Haskell,<br>applied to bioinformatics (again, can't find the paper).<br><br>Example<br>{<br>&nbsp; The goal was to implement a super-fast algorithm.&nbsp; The catch was, the<br>&nbsp; resulting program has to accept a rather big number of parameters.<br>&nbsp; Written directly in C, the fact that those parameters changed meant<br>&nbsp; the main loop had to make several
 checks, slowing the whole thing<br>&nbsp; down.<br><br>&nbsp; So they did an EDSL based on monads that basically generated a C<br>&nbsp; program after the parameters were read and knows, then ran it.&nbsp; Not<br>&nbsp; quite Just-In-Time compilation, but close.&nbsp; The result was of course<br>&nbsp; noticeably faster than the original C program.<br>}<br><br>Therefore, I'm quite optimistic.&nbsp; My best guess right now is that smart<br>compilers will be more than enough to make Frank "fast enough", "as fast<br>as C"[1] or possibly even faster, for 2 reasons:<br><br>1. As far as I know, most languages in Frank are quite specialized.<br>&nbsp;  That prior knowledge can be exploited by compilers.<br>2. The code volume is sufficiently small that aggressive whole program<br>&nbsp;  optimizations are actually feasible.<br><br>Such compilers may cost 10 to 100 thousands lines or more, but at least<br>those lines would be strictly contained. Then, potential
 end users<br>wouldn't give up too much hackability in the name of performance.<br><br>[1]: <a href="http://c2.com/cgi/wiki?AsFastAsCee" target="_blank">http://c2.com/cgi/wiki?AsFastAsCee</a><br><br>Loup.<br>_______________________________________________<br>fonc mailing list<br><a ymailto="mailto:fonc@..." href="mailto:fonc@...">fonc@...</a><br><a href="http://vpri.org/mailman/listinfo/fonc" target="_blank">http://vpri.org/mailman/listinfo/fonc</a><br><br><br>
</div> </div> </blockquote>
</div>   </div></div>
K. K. Subramaniam | 8 Feb 16:43 2012
Picon

Re: Raspberry Pi

On Wednesday 08 Feb 2012 7:50:34 AM Jecel Assumpcao Jr. wrote:
> That is a very good point, but the reason why I have tried to design my
> computers with 100% removable media is so they can be shared in a
> classroom. Even at $35 a class might not have one per student. If you
> have 10 machines and 30 students, each with their own SD card, it works
> better than if you have permanent stuff inside each computer. Though
> today's users have learned to cope with hard disks and installing
> software, the old floppy-only machines were actually easier for them.
+1. A second reason to have shareability is reuse. In a classroom the utility 
of projects are primarily in the lessons learnt while building it, not in its 
end use. So it makes sense  to be able to dismantle it and reuse it for 
another project.

Regards .. Subbu

Gmane