Re: MISC-d Digest V00 #20; Linux+Toas+Mips.
- To: kc5tja@xxxxxxxxxxx, waynemm@xxxxxxxxxxx
- Subject: Re: MISC-d Digest V00 #20; Linux+Toas+Mips.
- From: "Wayne Morellini" <waynemm@xxxxxxxxxxx>
- Date: Thu, 11 May 2000 15:13:47 EST
- Cc: misc
Sorry for the delay. I'm impressed by your speed of reply, unfortunately
this mail server fell over before I could read it.
>From: "Samuel A. Falvo II" <kc5tja@armored.net>
>To: Wayne Morellini <waynemm@hotmail.com>
>CC: misc@pisa.rockefeller.edu
>On Tue, 9 May 2000, Wayne Morellini wrote:
>
> > Now I remember, not Nintendo but the Dolphin Forth OS project, how is
>that
>Well, Dolphin isn't a Forth OS, and never has been. It's original
>purpose, way, way, way back when, was to allow me to develop Forth apps
>using a Visual C/BASIC type development environment. I kind of grew in
>scope since then. ;)
>
>Now, Dolphin will be a 32-bit, protected mode, multitasking operating
>system kernel, with native support for a CORBA compatible object system.
Well I'm impressed, this is just the progressive thinking needed in Forth.
> > 10K translator sounds good for a Misc p32. Instantly you can say to
>your
>
>Yup. Although Dolphin is currently written for PCs using straight C, I
>*really* want to make it run on a virtual processor environment that's
>specifically optimized for a run-time object system, that's still designed
>primarily for native code re-compilation. Neither Java nor TAOS are fit
>this goal, and furthermore, their security and protection models are
>abysmal.
My plan isn't, but it is different. If the virtual code speed isn't a
problem I enourage you to look at it any way, anything is better than
nothing.
>
> > companies. But the Toas virtual code system can work much faster on
>many
> > machines (but not Misc), and Toas outperforms Java in almost every
>technical
> > arena now. Also there is some form of pocket Linux being worked upon.
>
>Why can't TAOS be ported to MISC?
It's just that Toas isn't a dual stack based model, and face it, Misc can
pull the Mhz but memory and instruction set wise you are facing big
performance hits (no flames a 500Mhz machine that can barely keep up with a
50Mhz pentium on integer is going to suffer when made to emulate non stack
32-bit codes). So the only answer is a stack based virtual engine.
>
>I have to admit, because of the numbers involved, I'd have to optimize my
>virtual processor's code for compilation on a register oriented machine,
>such as x86 or PowerPC.
Yes I know what you mean:
>
> > I am happy to see somebody finally implementing this sort of stuff.
>
>No kidding! :)
Keep in contact, it would be good to see.
Wayne
Wayne
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com