Rethinking Java on SEAForth - GA chips

Hello all,

I've rethought my position on whether or not Java could run with
satisfactory performance on a
SEAForth or GA architecture. After some thought I think my original
position was wrong and
it could be done. Here's why. First the problem I was worried about
is covered in Stephen
Pelc's DDJ article.

http://www.ddj.com/hpc-high-performa...ting/210603608

Stephen points out the differences between the Forth VM and a typical
C VM, how some
of the limitations of the Forth VM for DSP have been overcome by the A
and B registers,
but how the c18 VM still lacks certain elements needed for C style
frame pointer access.
A Java VM would face similar challenges.

But there seems to be a way around this. First Jeff Fox mentioned
that iTV had a Java
implementation. (I'd give almost anything to see the old iTV code for
this and other
applications). More relevant, however, seems to be John Rible's
presentation on eForth.
It uses memory stacks as well, though in a traditional Forth way as
opposed to a
Java way. They created their own SDRAM controller in software using
some of the cores.
According to John, random access is slow because "SDRAM random access
is slow".
But he said that streaming data could be done at near chip speed. (No
issue streaming
Java bytecodes). So if you can stream data in at near chip speed,
efficiently manage
stacks in memory as opposed to on chip, and do this with lots of cores
left over, there's
no reason I can think of that you couldn't run Java.

I still don't think Java is as important to cell phone sales as once
thought based the
iPhone's success, but for midrange phones where the makers can't
expect companies
to trip over themselves to make custom apps it certainly does make a
difference.
By contrast every phone has to do the equivalent of software defined
radio. If
Java could be implemented with enough cores left over for SDR that
might make
an impact in the market. (Switching between Java and other apps like
SDR
wouldn't be viable I think because of the time lost reconfiguring the
chip multiple
times per second.)

Anyway, my two cents.

Regards,

John M. Drake

Op Wed, 15 Jul 2009 09:10:19 -0700 (PDT) schreef jmdrake:

> Hello all,
>
> I've rethought my position on whether or not Java could run with
> satisfactory performance on a
> SEAForth or GA architecture. After some thought I think my original
> position was wrong and
> it could be done. Here's why. First the problem I was worried about
> is covered in Stephen
> Pelc's DDJ article.
>
> http://www.ddj.com/hpc-high-performa...ting/210603608
>
> Stephen points out the differences between the Forth VM and a typical
> C VM, how some
> of the limitations of the Forth VM for DSP have been overcome by the A
> and B registers,
> but how the c18 VM still lacks certain elements needed for C style
> frame pointer access.
> A Java VM would face similar challenges.
>
> But there seems to be a way around this. First Jeff Fox mentioned
> that iTV had a Java
> implementation. (I'd give almost anything to see the old iTV code for
> this and other
> applications). More relevant, however, seems to be John Rible's
> presentation on eForth.
> It uses memory stacks as well, though in a traditional Forth way as
> opposed to a
> Java way. They created their own SDRAM controller in software using
> some of the cores.
> According to John, random access is slow because "SDRAM random access
> is slow".
> But he said that streaming data could be done at near chip speed. (No
> issue streaming
> Java bytecodes). So if you can stream data in at near chip speed,
> efficiently manage
> stacks in memory as opposed to on chip, and do this with lots of cores
> left over, there's
> no reason I can think of that you couldn't run Java.
>
> I still don't think Java is as important to cell phone sales as once
> thought based the
> iPhone's success, but for midrange phones where the makers can't
> expect companies
> to trip over themselves to make custom apps it certainly does make a
> difference.
> By contrast every phone has to do the equivalent of software defined
> radio. If
> Java could be implemented with enough cores left over for SDR that
> might make
> an impact in the market. (Switching between Java and other apps like
> SDR
> wouldn't be viable I think because of the time lost reconfiguring the
> chip multiple
> times per second.)
>
> Anyway, my two cents.
>
> Regards,
>
> John M. Drake

Could you _please_ make your lines shorter. This wrapping is
distracting.
It is not my newsreader, even the wretches G.Groups does this.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

I'll bite.. :-)

[snip]
> According to John, random access is slow because "SDRAM random access
> is slow".
> But he said that streaming data could be done at near chip speed. *(No
> issue streaming
> Java bytecodes). *So if you can stream data in at near chip speed,
> efficiently manage
> stacks in memory as opposed to on chip, and do this with lots of cores
> left over, there's
> no reason I can think of that you couldn't run Java.
>

I think the performance gain from 'streaming bytecode' are going to be
minimal and you'll be stalling/jumping all over the place based on the
fact that code rarely streams well. That's one of the reasons we have
L1/L2 caches, something you'd have a hard time filling on GA/SeaForth.
You can port Java or any other VM to almost any type of hardware you
want, you'll just have to make some concessions on performance and
implementation :-)

In general, I think GA/SF are best suited to doing *custom*
applications with some sort of an interface to the outside world. That
way, you can stick an ARM next to a GA and have the best of both
worlds.

-Mux

Coos Haak wrote:
> Op Wed, 15 Jul 2009 09:10:19 -0700 (PDT) schreef jmdrake:
>
>> Hello all,
>>
>> I've rethought my position on whether or not Java could run with
>> satisfactory performance on a
>> SEAForth or GA architecture. After some thought I think my original
>> position was wrong and
>> it could be done. Here's why. First the problem I was worried about
>> is covered in Stephen
>> Pelc's DDJ article.

...

>> I still don't think Java is as important to cell phone sales as once
>> thought based the
>> iPhone's success, but for midrange phones where the makers can't
>> expect companies
>> to trip over themselves to make custom apps it certainly does make a
>> difference.
>> By contrast every phone has to do the equivalent of software defined
>> radio. If
>> Java could be implemented with enough cores left over for SDR that
>> might make
>> an impact in the market. (Switching between Java and other apps like
>> SDR
>> wouldn't be viable I think because of the time lost reconfiguring the
>> chip multiple
>> times per second.)
>>
>> Anyway, my two cents.
>>
>> Regards,
>>
>> John M. Drake
>
> Could you _please_ make your lines shorter. This wrapping is
> distracting.
> It is not my newsreader, even the wretches G.Groups does this.

Definitely not your (or my) newsreader. Could it be John's?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Oddly enough it does't wrap while I'm typing the message
but it does while when I read it. I'm not sure what the
optimal chars per line is. I'll test this out.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+

Jerry Avins wrote:
> Coos Haak wrote:
> > Op Wed, 15 Jul 2009 09:10:19 -0700 (PDT) schreef jmdrake:
> >
> >> Hello all,
> >>
> >> I've rethought my position on whether or not Java could run with
> >> satisfactory performance on a
> >> SEAForth or GA architecture. After some thought I think my original
> >> position was wrong and
> >> it could be done. Here's why. First the problem I was worried about
> >> is covered in Stephen
> >> Pelc's DDJ article.
>
> ...
>
> >> I still don't think Java is as important to cell phone sales as once
> >> thought based the
> >> iPhone's success, but for midrange phones where the makers can't
> >> expect companies
> >> to trip over themselves to make custom apps it certainly does make a
> >> difference.
> >> By contrast every phone has to do the equivalent of software defined
> >> radio. If
> >> Java could be implemented with enough cores left over for SDR that
> >> might make
> >> an impact in the market. (Switching between Java and other apps like
> >> SDR
> >> wouldn't be viable I think because of the time lost reconfiguring the
> >> chip multiple
> >> times per second.)
> >>
> >> Anyway, my two cents.
> >>
> >> Regards,
> >>
> >> John M. Drake
> >
> > Could you _please_ make your lines shorter. This wrapping is
> > distracting.
> > It is not my newsreader, even the wretches G.Groups does this.
>
> Definitely not your (or my) newsreader. Could it be John's?
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿ ½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï ¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿ ½ï¿½ï¿½ï¿½ï¿½

Coos Haak wrote:

> Could you _please_ make your lines shorter. This wrapping is
> distracting.
> It is not my newsreader, even the wretches G.Groups does this.
>
> --
> Coos
>
> CHForth, 16 bit DOS applications
> http://home.hccnet.nl/j.j.haak/forth.html

Oddly enough the above wraps (on G.Groups anyway).

jmdrake wrote:
>
> Coos Haak wrote:
>
>> Could you _please_ make your lines shorter. This wrapping is
>> distracting.
>> It is not my newsreader, even the wretches G.Groups does this.
>>
>> --
>> Coos
>>
>> CHForth, 16 bit DOS applications
>> http://home.hccnet.nl/j.j.haak/forth.html
>
> Oddly enough the above wraps (on G.Groups anyway).

It wraps for me too. I'm so used to this annoyance that I didn't notice.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Mux wrote:
> I'll bite.. :-)
>
> [snip]
>
> I think the performance gain from 'streaming bytecode' are going to be
> minimal and you'll be stalling/jumping all over the place based on the
> fact that code rarely streams well. That's one of the reasons we have
> L1/L2 caches, something you'd have a hard time filling on GA/SeaForth.
> You can port Java or any other VM to almost any type of hardware you
> want, you'll just have to make some concessions on performance and
> implementation :-)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

You may be right. It would be interesting to see what kind
of Java performance the i21 got. (Note: Looking back at
earlier messages I didn't see Jeff say he had Java working
on an iTV, but that seems to be implied from this:

"Optimizing a Java implementation on a chip like F21 or i21 with
megabytes of addressable external memory and stacks but no local
RAM is fairly straightforward. Mapping it to tiny parallel
processors is a very different problem. One might be able to
make a virtual java processor with a bunch or small Forth
core but it is a problem I haven't looked into."

Also the iTV website mentioned Java.

http://web.archive.org/web/199902181...om/Technology/
It would be interesting to see what the performance numbers from such
a setup.

> In general, I think GA/SF are best suited to doing *custom*
> applications with some sort of an interface to the outside world. That
> way, you can stick an ARM next to a GA and have the best of both
> worlds.
>
> -Mux

Oh I agree whole heartedly. I put this up because I was wrong
about some of the previous arguments I made and for sake of
discussion. One way to do a lot of applications would be to
let the ARM handle the boring stuff (JVM, Linux, whatever) and
use the SEAForth / GA for all of the interesting stuff (video,
sound, voice recognition, etc). Of course if you can get
decent performance using X number of cores and still have
enough left for whatever it is you're trying to do then that's
not a bad result either. It all depends on how the numbers
come out.

John

Op Wed, 15 Jul 2009 10:47:05 -0700 (PDT) schreef jmdrake:

> Coos Haak wrote:
>
>> Could you _please_ make your lines shorter. This wrapping is
>> distracting.
>> It is not my newsreader, even the wretches G.Groups does this.
>>
>> --
>> Coos
>>
>> CHForth, 16 bit DOS applications
>> http://home.hccnet.nl/j.j.haak/forth.html
>
> Oddly enough the above wraps (on G.Groups anyway).

I am responsible for the newline after "is" ;-)
In your other message, 70 seems fine.

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

Sorry for the broken lines, I notice this does this sometimes and not
others, I usually manually remove the breaks, but the problem is a pain in
the..

On Thu, 16 Jul 2009 02:10:19 +1000, jmdrake <johnmdrake@gmail.com> wrote:

> Hello all,
>
> I've rethought my position on whether or not Java could run with
> satisfactory performance on a
> SEAForth or GA architecture. After some thought I think my original
> position was wrong and
> it could be done. Here's why. First the problem I was worried about
> is covered in Stephen
> Pelc's DDJ article.
>
> http://www.ddj.com/hpc-high-performa...ting/210603608
>
> Stephen points out the differences between the Forth VM and a typical
> C VM, how some
> of the limitations of the Forth VM for DSP have been overcome by the A
> and B registers,
> but how the c18 VM still lacks certain elements needed for C style
> frame pointer access.
> A Java VM would face similar challenges.
>
> But there seems to be a way around this. First Jeff Fox mentioned
> that iTV had a Java
> implementation. (I'd give almost anything to see the old iTV code for
> this and other
> applications). More relevant, however, seems to be John Rible's
> presentation on eForth.
> It uses memory stacks as well, though in a traditional Forth way as
> opposed to a
> Java way. They created their own SDRAM controller in software using
> some of the cores.
> According to John, random access is slow because "SDRAM random access
> is slow".
> But he said that streaming data could be done at near chip speed. (No
> issue streaming
> Java bytecodes). So if you can stream data in at near chip speed,
> efficiently manage
> stacks in memory as opposed to on chip, and do this with lots of cores
> left over, there's
> no reason I can think of that you couldn't run Java.

I appreciate your sincerity, I pretty much had independently accessed all
that last time. There are various ways to slice and dice the problem, as
with raytracing, and I do agree that software defined radio is big market
for manufactures to use. I actually had previously planned on doing
software defined radio myself for products earlier in the year (not that I
have any expertise in it, just know something interesting when I
see/access it). I often don't reveal what I am planning. I have not read
your post in the other thread, but it is my hope that you and Mux can work
together on 3D and have fun (I say 'fun' because 3D is fun).

The situation is that as the mobile phone chip-sets have now apparently
dropped so much in price, I will just add one of those if I need mobile
features. Products are a mountain of work, and I am not well enough to do
everything custom. Don't expect me to use anything but the cheapest phone
chip-sets anytime soon though, an Iphone level chip-set is expensive and
overshadow the value of the misc chip as a forth alternative platform.

> I still don't think Java is as important to cell phone sales as once
> thought based the iPhone's success, but for midrange phones where the
> makers can't
> expect companies to trip over themselves to make custom apps it
> certainly does make a
> difference.

If I had an product like the Iphone, as an initial competitor to the
Iphone years ago, then the press would be beating a path to my door out of
hype and curiosity. The truth is, that this particular phone is so nice
and branded (+istore software range and sdk) that it makes it's own sales
and software development, not to mention the money behind pushing ti too
customers. I am hoping to get a 3GS myself (finally one worth baying, but
still no video call camera). However, weather a Windows or Palm phone you
could dig into the Windows pocket or Palm app pool and largely not need
Java (except many conventional web pages used it). The Iphone nano (or
whatever they call it) in China will be interesting. An example of a
revolutionary custom phone (well windows mobile with custom features) that
did not succeed in these areas like Iphone did, has no Java and not many
custom apps (there has been workarounds to get window pocket apps working)
look at the originally neonode 's (I have a broken one here).

> By contrast every phone has to do the equivalent of software defined
> radio. If
> Java could be implemented with enough cores left over for SDR that
> might make
> an impact in the market. (Switching between Java and other apps like
> SDR
> wouldn't be viable I think because of the time lost reconfiguring the
> chip multiple
> times per second.)

Yes.


> Anyway, my two cents.
>
> Regards,
>
> John M. Drake

I agree, thanks for posting this too. Earlier this year I determined to
put the misc projects on hold, as everything is in flux again (pity, it
was getting out of flux end of last year), and I am not a large company to
pay somebody to chip away the welder's flux for me, or the health to do it
myself. I am thinking of going back and completing the science fiction
novel I started writing 16 years ago (Jeff's probably smiling as we
speak). I wrote a third of a draft in a week or so, so hopefully I can
complete it within the year. By then hopefully, the standard chips and
their coding should be set long term.


Wayne.

On Thu, 16 Jul 2009 03:35:18 +1000, Jerry Avins <jya@ieee.org> wrote:

> Coos Haak wrote:
>> Op Wed, 15 Jul 2009 09:10:19 -0700 (PDT) schreef jmdrake:

[broken lines]

>>> wouldn't be viable I think because of the time lost reconfiguring the
>>> chip multiple
>>> times per second.)
>>>
>>> Anyway, my two cents.
>>>
>>> Regards,
>>>
>>> John M. Drake
>> Could you _please_ make your lines shorter. This wrapping is
>> distracting.
>> It is not my newsreader, even the wretches G.Groups does this.
>
> Definitely not your (or my) newsreader. Could it be John's?
>
> Jerry

I have an option on mine to wrap lines, could it be something like on one
of their systems, or that your newsreader corrects to display?

The Internet, you have got to love it, to keep from being annoyed by it

On Thu, 16 Jul 2009 04:35:17 +1000, Jerry Avins <jya@ieee.org> wrote:

> jmdrake wrote:
>> Coos Haak wrote:
>>
>>> Could you _please_ make your lines shorter. This wrapping is
>>> distracting.
>>> It is not my newsreader, even the wretches G.Groups does this.
>>>
>>> --
>>> Coos
>>>
>>> CHForth, 16 bit DOS applications
>>> http://home.hccnet.nl/j.j.haak/forth.html
>> Oddly enough the above wraps (on G.Groups anyway).
>
> It wraps for me too. I'm so used to this annoyance that I didn't notice.
>
> Jerry

It is odd that the two messages after this are not being loaded into my
reader. Has been doing this with some messages this year, even if the
same poster just posted a displayable message just before to the same
thread, any suggestions as to why they don't load in?

Wayne.

On 15 July, 18:45, jmdrake <johnmdr...@gmail.com> wrote:
> Oddly enough it does't wrap while I'm typing the message
> but it does while when I read it. I'm not sure what the
> optimal chars per line is. I'll test this out.

I post from Google groups too and 68 characters per line is safe
although I think you can go 2-3 above that. Beyond that I think
Google software itself wraps the line before posting the article on
Usenet. It is safer to prepare your message in a text editor and
then cut and paste rather than write it directly on your browser's
window.

Also Google groups does not wrap long links surrounded by < > as in
< rrrrrrrrrrrrrrrreeeeeeeeaaaaaaaaaallllllllllyyyyyy y-
llllllllllllllooooooooooooooonnnnnnnggggggg-llllliiiiink >

Spiros Bousbouras wrote:
> On 15 July, 18:45, jmdrake <johnmdr...@gmail.com> wrote:
>> Oddly enough it does't wrap while I'm typing the message
>> but it does while when I read it. I'm not sure what the
>> optimal chars per line is. I'll test this out.
>
> I post from Google groups too and 68 characters per line is safe
> although I think you can go 2-3 above that. Beyond that I think
> Google software itself wraps the line before posting the article on
> Usenet. It is safer to prepare your message in a text editor and
> then cut and paste rather than write it directly on your browser's
> window.
>
> Also Google groups does not wrap long links surrounded by < > as in
> < rrrrrrrrrrrrrrrreeeeeeeeaaaaaaaaaallllllllllyyyyyy y-
> llllllllllllllooooooooooooooonnnnnnnggggggg-llllliiiiink >

You may be no spaces, so:
<rrrrrrrrrrrrrrrreeeeeeeeaaaaaaaaaallllllllllyyyyy yy-llllllllllllllooooooooooooooonnnnnnnggggggg-llllliiiiink>
Of course, maybe it has to be a valid link.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Op Thu, 16 Jul 2009 06:07:26 -0700 (PDT) schreef Spiros Bousbouras:

> On 15 July, 18:45, jmdrake <johnmdr...@gmail.com> wrote:
>> Oddly enough it does't wrap while I'm typing the message
>> but it does while when I read it. I'm not sure what the
>> optimal chars per line is. I'll test this out.
>
> I post from Google groups too and 68 characters per line is safe
> although I think you can go 2-3 above that. Beyond that I think
> Google software itself wraps the line before posting the article on
> Usenet. It is safer to prepare your message in a text editor and
> then cut and paste rather than write it directly on your browser's
> window.
>
> Also Google groups does not wrap long links surrounded by < > as in
> < rrrrrrrrrrrrrrrreeeeeeeeaaaaaaaaaallllllllllyyyyyy y-
> llllllllllllllooooooooooooooonnnnnnnggggggg-llllliiiiink >

You posted on google, the line wrapped after the minus sign.
Jerry used Thunderbird, my 40tude does not wrap his line,
Google Groups still does. One more reason not to use it ;-(
--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html