Ken Shillito wrote:
> > by twiddling with the code. The whole architecture of the OS is far
> > slicker than many others. And yes, before 100 people point it out,
> The resons the Amiga`s OS is so efficient include:
> 1. Amiga's messages between tasks send pointers to the memory of the
[...]
> 2. Amiga does not do resource tracking. That is why if you get a GURU
[...]
> The above won't do for JAVA, if it it to be used by WWW browsers, for
> the following reason. When JAVA runs an applet, it creates for the
> applet a thing known as a "sandbox" (based on the notion that a sand
The points you make above are indeed some core reasons how the AmigaOS
retains some of its speed. However, in relation to a Java engine it
does not have to be a concern. Since the JVM has to do some sort of
interpretation of the bytecode, whether it be JIT compile or
interpet-as-it-goes or whatever, the real Amiga CPU is not actually
running the bytecode. It is in effect executing subroutines or code
fragments which provide the functionality required. It is therefore
possible to include memory protection and other features in the
abstraction layer between the two. In fact, emulators in general, such
as those to emulate a PC, C64, Spectrum, SNES, etc, build themselves a
"virtual machine" inside the Amiga, and no amount of clever coding on
the emulated machine can affect the host system.
Ok, a JVM is not quite the same, as it is more generalised and
targetted at system level resources, but the principle remains valid.
> By the time code is written to do these things, it all starts getting bogged
> down.
True. Adding in all these exception and addition cases does make it
slow. I deliberately did not mention above a Mac emulator, such as
ShapeShifter, where the host CPU does run the emulated code directly.
This does lead to serious complications in keeping the systems
seperate, but is distinctive in its much greater speed of "emulation".
Still is does not prevent, in principle, features to be included which
are not directly part of the host OS, but it does make them a great
deal harder to implement.
> The best way to make a JVM fast would be to make a hardware plug-in
> so you could have a "JAM" (Java Actual Machine). A JAM run by an
> Amiga would be faster than a JVM run by a PC.
ISTR that somebody did introduce a CPU which would run Java bytecode
directly. How far that extended into producing the kind of JAM you
refer to I do not know, nor whether it was commercially successful.
Apologies if this is getting OT.
Regards,
Ian
===
_____________________________________________________________________
Voyager Mailing List - http://v3.vapor.com/
Voyager FAQ....: http://faq.vapor.com/voyager/
Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP
Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE
