Inner loop compiler
Hi Barbarella,
>First to you, Mike,
>>Yes, although the [more] Euphoric it is the better I say.
>If by 'Euphoric' you mean 'flexible and easy to use', I'm afraid my
>plans does not go in that direction.
>For the inner loop, I'd like to sacrifice flexibility and ease of use
>for safety and speed whenever possible.
>>I have often thought about the usefulness of such a system and if I
>>believed my namesake (MTS) then a more comprehensive compiler/converter
>>already exists. Getting access to it might be a problem though.
>That's interesting! Would you please tell me more about the system you
>have been thinking about?
>Maybe you could even expand a little bit on how it compares to your
>perception of my extremely unclear plans?
In recent years a gentleman called Mike the Spike (MTS) used to frequent
the Euphoria mailing list and he
apparently wrote a Euphoria to C translator which was claimed to produce
lightning code. I sometimes wonder
if some list readers thought that MTS' claims were a merely ploy to
prompt Rob to write his translator.
As you will know the RDS translator *is* in existence and, at the risk
of seeming disloyal to Rob,
let's just us say it could be faster. Anyway, a search on this mailing
list should give you enough
background info about all of this.
After reading your earlier thoughts on what you may wish to achieve it
seems to me there is
practically no end of the complexity that a compiler could have and I
agree that
"minimalist, simple, safe and fast" are desirable attributes. I wonder
if you might
consider a more generic approach in that the "language" could be
modelled on Euphoria.
You could have a simplified version of the syntax which converts to asm
and then
machine code by using asm.e
Since tight code loops are an obvious starting point for speed-up you
could focus on those
sorts of constructs, eg:
This line of code...
integer plot_x, plot_y
plot_y = 10
for i = 1 to 100
plot_x = i
PlotLine()
end for
..is converted into..
def int plot_x, plot_y
mov eax, #000A
mov [plot_y], eax
mov ecx, #0001
loop: push ecx
mov [plot_x], ecx
call PlotLine
pop ecx
inc ecx
cmp ecx, #0064
jmpgt loop
Please excuse this code travesty but I'm sure you get the picture.
Just a few ideas..
i) Since Eu's integer size is a subset of asm 32-bit integer type why
not just assume all integers
are 32 bits? It is not as if the machine code is going to call a
Euphoria routine, is it.
ii) All variables could simply have their own memory location instead of
being forced into a register.
This would make the project much easier to write and register
optimisation could be left till
later, if at all.
iii) loop variables *could* have their own register but what happens for
several nested loops?
iv) Leave out all: labels, GOTO's and any other nasty C stuff, and don't
listen to anyone
that tells you otherwise.
v) There are times when the result of a floating point operation should
be converted to an integer so
why not provide automatic conversion (for declared atoms) in such cases
(also the reverse one too)?
vi) Since all variables have their own memory location then you could
pass sub-routine parameters
using registers. Of course, there would be a limited number to go around
but still, it is an idea..
Maybe a better idea is to have a stack that parameters can be pushed
onto and a register is used
to advise the called routine just how many parameters are available to
use..
vii) Include a provision to decode expressions, someone must know how to
do this.
Regards,
Mike
|
Not Categorized, Please Help
|
|
