Hello All,
On Fri, May 5, 2001, at 02:18 PM, Ian wrote:
>
> 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
> ===
I shall state something very heretical, "Do you think it
might be the right time to consider officially involving the
people who have worked on AWeb and IBrowse, as well as those
working on Voyager, for the purpose of establishing a workable
JAVA which can be used by the Amiga browsers?" I am only asking
this because obviously there is a perceived need for have Amiga
browsers JAVA enabled, but, no one seems to be able to do it
alone, which also means that on one Amiga brower team has had
any real success, also. In fact, it appears that the only thing
of which can be agreed is the existence and workability of Kaffe.
Might I add that contacting the author of Kaffe, to help in
effecting its use with one of the Amiga browsers.
Anyway, this is just my thought and question.
Regards,
Julian.
--------------------------------------------------------
Author of "MSH Tutorial V. 3.0". Found on Aminet -- MSHTut30.lha
Julian Aronowitz. Tel.: (718) 654-1681;
E-Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
_____________________________________________________________________
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
