Re: Anouncing: Mike's Turbo Euphoria!
--- Euman <euman at BELLSOUTH.NET> wrote:
> Try
> /* parser.c
> The big freakin' parsing machine...
> Pete Eberlein <xseal at harborside.com>
> */
> Pete already has the code layed out.
Heh? Wha?
What's parser.c? Isn't that the parser used by PEU?
I any case, I can't create a Euphoria library using .c
files...
> The only significant enhancement your code will
> bring
> is preprocessed information which anyone can write
Wha? And what about the Euphoria To Machine Code
translation then? Can anyone write *that*?
> The amount of math to be done will shorten
> but, the pointers to sequences will not. On the fly
> math procedures will not.
Not what? It'll be 200-300 times faster than Euphoria
with math on integers.
And there is no way to get a pointer to a sequence in
Euphoria. And even if there was, it wouldn't do you
any good.
> We already know that Euphoria's main stay are
> sequences.
Yeah, but a slow-ass interpreted graphics blitter
using sequences is worse than a Machine Code Euphoria
graphics blitter using pokes.
> So tell me, what difference will this make?
It'll let you code ASM routines in Euphoria, that's
the diff. It translates Euphoria into Machine Code.
That means you can implement speed-critical code in
Machine Code without having to know how to code in it.
That means you write a Euphoria routine that runs
faster than compiled C (in some cases), and call it
from interpreted Euphoria.
But in any case, this lib is becomming a drag to
debug. A single error in the ASM code produced and I
get a GPF or a Causeway crash. I dunno why I got
myself into this one, it's coding someone like Pete
can do faster than me.
Mike The Spike
__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
|
Not Categorized, Please Help
|
|
