Just a few notes thrown in here too... =)
> What Kasper is proposing is, essentially, a Newton virtual
> machine written
> in Java.
no.. sorry, thats not it, i do not intent to emulate anything but the look
and feal of the newton.. writing a newton emulator in java, would simply be
too slow to be functional...
> 1. Java, in most versions, is an interpretive language. Therefore, the
> emulation would be necessarily slow.
heres a bit about javas speed, which seems to be the main question posed
both by dave and gary...
JITs are actually getting quite clever these days... but, the interpretation
of java bytecode is actually not where the cpu cycles are spend.. Looking
back at the old Jdk 1.1.7 for windoze, over 40% of all cpu cycles used by
the java vm, was actually used by the garbage collector, and the synch.
locking mechanisms. The newest generations of java, such as hotspot are
using better locks, and an advanced generational garbage collector.. this
has narrowed these parts down to only taking about 10% which is actually not
that bad! most good c++ garbage collectors are around that 5-10% too...
So how is the performance of the remaining 90% of the cpu cycles.. well, if
you do straight measurements, for stuff like adding, subtracting, dividing
and such, it's about 10% slower than C++.. the only place where it is a lot
slower, is for object creation, this takes almost 10 times the time of what
c++ takes, even when c++ is running with a garbage collector! When needed,
the work around for this, is to use object pools..
Anyways, the general performance of java, is good enough for the gui and
apps (will certainly be faster than newtonscript), and for those places
where speed REALLY is needed like the handwritting recognizer, I propose
that a platform independant java version is written, so that it will run
anywhere, but there is no problem in also having native versions written in
c for specific platforms. Java handles C libraries quite nicely...
> 2. A native Java compiler could deal with this, but that would
> have to be
> ported to each individual platform, and these could *not* be done
> in Java,
> since Java is not a "fertile" language. C or assembler could be used to
> develop the compiler ports, but...WOW!, what a job.
sorry, java works fine for developing cross platform compilers... for my 4th
semester project i created a simple self inspired language, and developed a
compiler in java which would create x86 native code.. as you might have
guessed, the theme for that semester was the awfull "dragon book"...
> 5. There are several small-footprint Java initiatives, like Sun's Jini,
> Aplix, and others. Some are designed for embedded systems,
> similar to the
> NewtonOS in ROM.
yup... i would suggest using PersonalJava, since it is the platform which is
being ported to handhedl devices...
> IF some of these issues could be dealt with, combining the work David has
> done in Python, add in an HWR engine like Rosetta based on the
> work of Larry
> Yaeger and the ATG
> (http://www.beanblossom.in.us/larryy/ANHR.html), code it
> in portable Java, et viola! Freeze-dried Newton...Just add hardware! :)
excatly, that was my main point.. not to be dependant on hardware.. someone
quits producing your platform?.. not a problem, just switch and boot up
again :)
regards
Kasper
******************************************
This NewtonTalk Message brought to you by:
EVOTE.COM, the ESPN of Politics on the
Internet. Visit EVOTE.COM for all the latest
news on Campaign 2000!
Visit http://www.evote.com today!
******************************************
Need Subscribe/Unsubscribe Info?
visit http://www.planetnewton.com
******************************************
This archive was generated by hypermail 2b29 : Wed May 03 2000 - 09:41:11 EDT