Re: mac.exe

new topic     » goto parent     » topic index » view thread      » older message » newer message

snortboy:
>What is the likelihood of ex.exe or exw.exe running
>under an emulator?
theory says that if it's a *good* emulator, that it
will function as an emulator and emulate what it's
supposed to be emulating. ;)
what that means to me is, the likelihood _should_
be high with a good emulator, and low with a bad one.

>Or, contrarily, how hard would it be to port it to
>something like "mac.exe" or is that totally wacko?
>Cuny, David wrote:
>As a result, porting C programs from the PC to
>the Mac can be less than trivial, especially if
>they rely heavily on pointers - and Euphoria and
>Pete's Euphoria clone fall into that category.
okay, in this arena i know enough to be only dangerous,
but perhaps not correct.  my recollection of ANSI C
intention/definition is such that, if you write
a program that is truly ANSI C and then recompiled
that program on another platform, it should work, no?
now of course, with all it's extreme optimization,
Euphoria wouldn't recompile cross-platform, and
PEU may not by now.  but, what if, PEU was taken
back to a stage that was ANSIc and we began there?

>If the Euphoria interpreter spit out bytecodes
>(or Java bytecodes),
allright...
the way i understand bytecodes actual "function"...
ergo: how it does what it does...
every reserved word has a "universal" identifier
and after that point, each variable gets it's own
moniker.  then an interpreter that understands
this universal language, reads these codes and
executes them in a linear fashion.
what we then need are 3 things:
  1>interpreters (run time executors) for all platforms
    that understand "universal"
  2>translators for all platforms that take .e and
    .ex files and spit out "universal"
  3>the actual definition of "universal"
not necessarily in this order :>

#3 doesnt seem so bad... especially with EU...
it gets a little gnarly tho, because of the following:
  the byte is a universally understood storage medium.
  but a byte can only hold 256 individual values, meaning
  no more than 256 reserved words and variables *combined*.
myself, i can use 256 variables alone, in a real big hurry,
not counting reserved words...
allright you say, lets use int.  everyone has int, right?
well, int varies like *alot* not just between platforms,
but sometimes within platform as well. EU has enormous
int, but pascal is like -32K..32K (or -64..64 is it?)...
either way... pascal's is much much smaller...
well this descrepancy wouldn't be tolerable for this type
of affair.
we're left then with what i believe java prolly does..
char... actually dual char i think... sets of pairs
of characters representing reserved words.
well that's good you say, but what about our precious
variables, and data, and constants, and strings and
the like?
unless i'm mistaken again, we cheat. one of the reserved
word 'tokens' tells the translator(run time) that what
is to follow (and for how long) will be a value,
or a variable name, or a constant... one token for each
of these (and other) possibilites.

when you look at it from this standpoint, be my understanding
actually right or wrong of how "java" (or any other bytecode
language) does it, it begins not to look quite so daunting.

another thing that looking at it this way reveals, especially
with euphoria, is that 256 reserved words might actually
work out to be "alot"...
at this point i think i should pointout & clarify "reserved
word" here... that would be all EU builtin func/proc names,
as well as all the math/boolean/sequence operators.
we can leave the operators as they sit, no need to translate
them as they already have a value from 0-255...cool...
life made easy already...
now we simply give the reserved "words" a value from the ones
left over, and we'll need to reserve a couple more for helping
to define variables/values/constants.  let's suppose we pick
12 as the number for "sequence".  we need another number
to represent "how many of the following bytes are to be used
as the name of this variable" or, hrmmm... for that matter,
whitespace can be real damned handy here as i think about it.
not to mention the {} and the ','.
something like:
   sequence  abcd  {m,a,r,y, ,h,a,d, ,a, ,l,i,t,t,l,e}
could be turned into 'universal' rather easily in the
translator parser.
    12 65 66 67 68 (and then the { would let the parser
    know that the data was coming... you get the idea)

here's the neat part... reverse translators...
since euph (DOS) already understand .e and .ex then
we need only to reverse the algorithm for the DOS mode
translator to take a set of bytecode/tokens and make
ex.exe run this newly generated .ex file.  I see this
as being potentially handy, and perhaps powerfull indeed.
especially for the web... streaming euphoria? you could
make web pages that -executed- just like activeX and java
pages do...
how would this work? okay, lets say we start with saying
that from now on, .exb is the extension for Euphoria
eXecutable Bytecode.  we then need exb.exe which is the
ex.exe bound with a bytecode (universal) interpretive
front end.  the plugin would also be exb.exe.
someone downloads that, and associates *.exb with
exb.exe and whenever they click on a link that is like
    www.poot.com/game.exb
netscape is already smart enough to search for filetype
associations and spawn the proper program.
viola!

getting excited yet?
i don't think it would be that hard to make a DOS translator
from universal->.ex and .ex->universal?!?!? would it???

</endLengthyReply>

sowwy, got longwinded...
--Hawke'

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu