nanogui: Thread: MicroWindows, Java and desktop

I had a dream...
If we had a java VM running on MicorWindows or NanoX, then we could make a
java desktop ala PalmOS
My questions:
- do you know of a JVM running on nanoX/MW ?
- do you know a project of writing a tiny java desktop ala PalmOS (for PDAs)
?
- would someone interested in helping?

-jec

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
Jean-Eric Cuendet
Linkvest SA
Av des Baumettes 19, 1020 Renens Switzerland
Tel +41 21 632 9043  Fax +41 21 632 9090
http://www.linkvest.ch  E-mail: ####@####.####
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

> -----Original Message-----
> From: ####@####.#### ####@####.####
> Sent: Thursday, March 02, 2000 12:40 PM
> To: Jean-Eric Cuendet
> Subject: Re: MicroWindows, Java and desktop
> 
> 
> Since when are you going to run java on any thing less than a 
> pentium 70?

First, Java is not slow in itself. It can run quite as fast as standard
C/C++ code (not optimised). This is only a matter of JVM implementation and
JIT.
Then, there is already an implementation of KVM (by sun and Palm) that run
on 3com palmpilot (not available yet).
Third, there is some PDAs that are quite as fast as a P70, no? There is PDAs
with 100+MHz processor.
Fourth, the processors are made to be faster and faster. Wait only one year
and your processors will double their speed.

Don't you think it's enough and worth the try?
-jec

> 
> Imre
> 
> 
> > 
> > I had a dream...
> > If we had a java VM running on MicorWindows or NanoX, then 
> we could make a
> > java desktop ala PalmOS
> > My questions:
> > - do you know of a JVM running on nanoX/MW ?
> > - do you know a project of writing a tiny java desktop ala 
> PalmOS (for PDAs)
> > ?
> > - would someone interested in helping?
> > 
> > -jec
> > 
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > Jean-Eric Cuendet
> > Linkvest SA
> > Av des Baumettes 19, 1020 Renens Switzerland
> > Tel +41 21 632 9043  Fax +41 21 632 9090
> > http://www.linkvest.ch  E-mail: ####@####.####
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > 
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> > 
> 

How does one go about writing a Java VM.  
Is it written in C or some other language?  
Does it interpret the Java byte code?
I would be interested in perhaps a stand alone Java VM that could easily be
added to any embedded platform / PalmOS.  Although I do think very highly of
the Java coding I would be very interested in following what happen under
the hood.


Regards,
Rod Boyce
		-----Original Message-----
		From:	Jean-Eric Cuendet ####@####.####
		Sent:	Thursday, 2 March 2000 19:28
		To:	####@####.####
		Subject:	MicroWindows, Java and desktop


		I had a dream...
		If we had a java VM running on MicorWindows or NanoX, then
we could make a
		java desktop ala PalmOS
		My questions:
		- do you know of a JVM running on nanoX/MW ?
		- do you know a project of writing a tiny java desktop ala
PalmOS (for PDAs)
		?
		- would someone interested in helping?

		-jec

		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
		Jean-Eric Cuendet
		Linkvest SA
		Av des Baumettes 19, 1020 Renens Switzerland
		Tel +41 21 632 9043  Fax +41 21 632 9090
		http://www.linkvest.ch  E-mail: ####@####.####
		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 




	
---------------------------------------------------------------------
		To unsubscribe, e-mail: ####@####.####
		For additional commands, e-mail:
####@####.####

On Fri Mar 03, 2000 at 08:11:05AM +1300, Rod Boyce wrote:
> How does one go about writing a Java VM.  
> Is it written in C or some other language?  
> Does it interpret the Java byte code?
> I would be interested in perhaps a stand alone Java VM that could easily be
> added to any embedded platform / PalmOS.  Although I do think very highly of
> the Java coding I would be very interested in following what happen under
> the hood.

Mozilla has a JVM, doesn't it?  Seems like 
checking mozilla.org would be a good place 
to start.

 -Erik

--
Erik B. Andersen   Web:    http://www.xmission.com/~andersen/ 
                   email:  ####@####.####
--This message was written using 73% post-consumer electrons--

:How does one go about writing a Java VM.  
:Is it written in C or some other language?  
:Does it interpret the Java byte code?

Yes, java vm's job is to interpret byte codes.  Many
VM's are written in C, including Sun's reference port.
If you goto Sun's web page, you can go to the
developer site, and then fill out a long form
and say you're interested in Java for educational
purposes, they will allow you to download the
entire source code to their VM.  

Try it.  It's quite interesting reading.  Be prepared
for some late night study.

Regards,

Greg

I think it's not desirable to rewrite a Java VM. There exists some under
GPL. (www.kaffe.org and see links from there)
The goal would be to port it to microwindows which *should* be quite easy if
one good knows micorwindows/nanoX
Interested?

-jec

> -----Original Message-----
> From: Rod Boyce ####@####.####
> Sent: jeudi, 2. mars 2000 20:11
> To: ####@####.####
> Subject: RE: MicroWindows, Java and desktop
> 
> 
> How does one go about writing a Java VM.  
> Is it written in C or some other language?  
> Does it interpret the Java byte code?
> I would be interested in perhaps a stand alone Java VM that 
> could easily be
> added to any embedded platform / PalmOS.  Although I do think 
> very highly of
> the Java coding I would be very interested in following what 
> happen under
> the hood.
> 
> 
> Regards,
> Rod Boyce
> 		-----Original Message-----
> 		From:	Jean-Eric Cuendet ####@####.####
> 		Sent:	Thursday, 2 March 2000 19:28
> 		To:	####@####.####
> 		Subject:	MicroWindows, Java and desktop
> 
> 
> 		I had a dream...
> 		If we had a java VM running on MicorWindows or 
> NanoX, then
> we could make a
> 		java desktop ala PalmOS
> 		My questions:
> 		- do you know of a JVM running on nanoX/MW ?
> 		- do you know a project of writing a tiny java 
> desktop ala
> PalmOS (for PDAs)
> 		?
> 		- would someone interested in helping?
> 
> 		-jec
> 
> 		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> 		Jean-Eric Cuendet
> 		Linkvest SA
> 		Av des Baumettes 19, 1020 Renens Switzerland
> 		Tel +41 21 632 9043  Fax +41 21 632 9090
> 		http://www.linkvest.ch  E-mail: ####@####.####
> 		_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> 
> 
> 
> 
> 	
> ---------------------------------------------------------------------
> 		To unsubscribe, e-mail: 
> ####@####.####
> 		For additional commands, e-mail:
> ####@####.####
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

	It might be a little off-topic,  but I'd just like to mention one more aspect 
of Java in small devices,  one which has been forgotten by almost everybody.

	If you look in an operating system or computer architectures book,  you'll 
see that modern microprocessors devote an awful lot of transistors and 
switching events to providing the abstraction of virtual memory.  Think of it 
this way:  with each memory access,  the processor has to look up in a 
translation table to convert each logical address to a physical address.  It's 
quite amazing that you can do it without burning up much of your memory 
bandwidth.  Never mind the problems that virtual memory causes for designing 
cache systems.

	Also,  operating systems pay a high price in the time it takes to tear down 
and put up memory protection walls while context switching.  All that burns up 
CPU cycles,  time,  and ultimately battery power in small devices.

	Although most people like Java either because they think it's a nice language 
(I do,  but I've got plenty of friends who don't) and I think there are a lot 
of people who like Java because it's trendy.  The real technological 
innovation of Java,  however,  is the way the JVM provides memory protection 
in ~software~ with very little cost:  the verifier does a static safety check, 
 and then the code can be interpreted or translated with only a handful of 
runtime safety checks -- just array bounds checking and null pointer testing.

	Java Card is the most beautiful application of this technology yet.  It makes 
possible something the smart card industry has wanted for years:  a 
multiple-applications smart card.  Certainly it would be nice to load multiple 
applications on a smart card,  but it's also necessary to make sure you can't 
load an application which steals the private keys out of another application.  
 There just aren't enough transistors on a smart card for hardware memory 
protection,  and more conventional methods of software memory protection would 
have too great of a performance cost.

	Java would come into it's own in small devices that are based on RISC 
processors without virtual memory and with lightweight operating systems,  say 
exokernel based,  that use Java's memory protection for safety.  It's an 
interesting vision,  but we're already buying small devices with hardware 
memory protection and we're already running Linux on them,  so it might never 
materialize.

>  and then the code can be interpreted or translated with only a handful of 

I would have a hard time believing that the CPU and power required to do
interpretation of bytecodes is less than that required to support native
code executing in even a poorly designed VM subsystem.  As for compiling,
if you're going to compile on the fly, you take a big penalty for having
to include the compiler on the device and a big startup penalty to do the
compiles when the bytecodes are downloaded.  There aint no free lunch
when it comes to protection and I'll take hardware enforced mechanism over
software mechanisms any day of the week.


FM


--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

Jean-Eric Cuendet wrote:
 > 
 > I think it's not desirable to rewrite a Java VM. There exists some under
 > GPL. (www.kaffe.org and see links from there)
 > The goal would be to port it to microwindows which *should* be quite easy if
 > one good knows micorwindows/nanoX
 > Interested?
 > 


GNU JVM:

http://www.japhar.org/

License: LGPL

I do not know if this project is active.


NOTE: A team just completed the port of GJC to RTEMS.

Rosimildo.






______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

> this way:  with each memory access,  the processor has to look up in a 
> translation table to convert each logical address to a physical address.  It's 
> quite amazing that you can do it without burning up much of your memory 
> bandwidth.  Never mind the problems that virtual memory causes for designing 
> cache systems.

Actually

1.	You use lookaside buffers and because of locality you can hardly
	measure the overhead

2.	Caches are physically tagged and indexed nowdays. So no problem

> 	Also,  operating systems pay a high price in the time it takes to tear down 
> and put up memory protection walls while context switching.  All that burns up 

Its almost impossible to measure its so small

> CPU cycles,  time,  and ultimately battery power in small devices.

_battery power_ is a real one: See MMU's are gates and high speed logic,
no MMU - less gates.

> innovation of Java,  however,  is the way the JVM provides memory protection 
> in ~software~ with very little cost:  the verifier does a static safety check, 
Not a java innovation and they havent solved the memory fragmentation problem
without big overhead (handles)

>  There just aren't enough transistors on a smart card for hardware memory 
> protection,  and more conventional methods of software memory protection would 
> have too great of a performance cost.

Older CPU's used to get memory protection into < 1000 gates.

> interesting vision,  but we're already buying small devices with hardware 
> memory protection and we're already running Linux on them,  so it might never 
> materialize.

I take issue with your reinvention of history 8). MMUless devices can be
smaller, lower power and avoid some overheads. That I agree.

Now to get back on topic: nanogui doesnt need an MMU. I'd like to think it
can stay that way