Re: Euphoria To C Translator Optimisations (2)
--- Robert Craig <rds at RapidEuphoria.com> wrote:
> Rather than reply individually to the many posts
> made
> by Mike The Spike today, I'll just supply a
> few bits of information:
>
> ---
>
> register variables:
>
> Why don't you alter the C source
> files generated and tell me if "register" helps.
> WATCOM ignores register declarations.
> Most decent compilers do their own assignment
> of variables to registers. On the Pentium there
> aren't many registers available anyway.
Hmm...
Guess you're right...
I'm still living with my head in the 286 days anyways
:P
> ---
>
> *((int *)_2 = *((int *){9,34,14,18,33,46};
>
> Seems to me something like that only works
> for static initializations. Not dynamically
> executing code.
Yes, that's be cool for static sequence
initializations.
Then later on, code something like this;
_2[idx], it's more readble than _2+offset.
> ---
> in-lining:
>
> The routines that you want to inline are a bit too
> large.
Didn't know that, sorry :P
> inlining increases the size of your code, but does
> not necessarily increase the speed. There is a
> severe penalty for executing code that is not in the
> Pentium code cache. If your code is larger you will
> likely have more cache misses.
That's right...
Damn! That's what happens when you don't have the
soruce ;p
> ---
> peeks/pokes with DJGPP
>
> DJGPP puts low memory in a completely separate
> memory segment, so you have to call that go32 macro
> to peek or poke into it.
> WATCOM /Causeway made low memory contiguous
> with high memory in the same data segment. For
> compatibility
> I had to handle DJGPP this way. You really don't
> want me to put a single poke of one byte
> into memory into a subroutine, rather than
> *inlining* it
> would you?
That's right I guess :p
(tip: How about building up pokes so untill you have 4
of them, then poke an integer. This is a standard way
to quadrupple speed in mode 13h graphics coding. )
> ---
>
> #ifdef:
>
> The Euphoria source consists of *one* set of source
> files. There are #ifdef's throughout the code to
> select:
> Windows vs. DOS vs. Linux
> Public Domain vs Complete
> Translator vs Interpreter vs. Runtime Library
> Debug vs Release build
Wha?
So you're the same style of coder as me!! :p
Anyways, that means the code is extremely portable.
Add a new #ifdef, then the code for your platform.
> It would be potentially exciting to release the
> source
> to other people, but it has to be done in a way that
> maintains my income. I can't make any decisions
> about
> this for a couple of months (so stop nagging me
> 
).
LOL!
We discussed this ;)
A small subset of the interpreter, translator,
whatever, basically being your Euphoria code with the
platform-specific routines stripped out.
I don't see someone implementing poke(), call(),
open_dll(), pixel(), polygon(), sound(), draw_line(),
set_vector(), get_vector(), poke4(), peek(), peek4(),
etc, etc, ... for DOS32, Win32 and Linux, and then
sell it all as a Euphoria clone.
It took you nearly a decade to code all that stuff.
Aslong as that Portable Euphoria has append(),
prepend(), find(), match(), cos(), sin(), puts(),
gets(), getc() open(), close(), print(), get() and
printf(), we're all more than happy.
In other words, these libs are supported;
file.e
get.e
and these aren't;
image.e
dll.e
graphics.e
msgbox.e
machine.e
safe.e
Plus you can leave out tracing and/or profiling.
And, offcourse, you ship Portable Euphoria with the
full version of the translator and/or interpreter :p
So people gotta buy that first ;)
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
Later man!
Mike The Spike
PS. I won't bug you anymore :p
|
Not Categorized, Please Help
|
|
