1. RE: Inner loop compiler
- Posted by rforno at tutopia.com
Sep 01, 2002
Hi, Barbarella.
I'm a bit confused regarding what you are proposing. For example, do you
think it is possible to write fast compiled code without using assembly? If
so, how? At least, that is what I understood when you say there is no need
for assembly programmers.
Regarding some other issues, like rand() or time() routines, I could help if
needed, at the assembly level.
By the way, maybe you can explain what is the use Rob assigns to the
remaining bit of integers (32 bits - 31 bits = 1 bit). If not, maybe Rob
will do 
.
Regards.
----- Original Message -----
From: <OthelloVivaldi at hotmail.com>
Subject: Inner loop compiler
Hi, Everybody!
Are anyone here interested in looking into the possibilities
of a minimalist, compiled machine oriented language to be used
with Euphoria?
I would like the language to generate small routines that could
interface with Euphoria and speed up the inner loops of programs.
I would prefer to give safety, speed and simple design priority.
I've attached a zipped text file that describes my ideas in a
little bit more detail. Please remember it's just unclear
thoughts so far, much have yet to be worked out.
It would extremely nice to hear your opinion!
Yours Sincerely,
Barbarella
2. RE: Inner loop compiler
- Posted by rforno at tutopia.com
Sep 01, 2002
The attachment was plain text, wasn't it?
----- Original Message -----
From: Bernie Ryan <xotron at localnet.com>
Subject: RE: Inner loop compiler
>
>
> Mike wrote:
> > Hi Barbarella,
> >
> > > Hi, Everybody!
> > >
> > > Are anyone here interested in looking into the possibilities
> > > of a minimalist, compiled machine oriented language to be used
> > > with Euphoria?
> > Oh, by the way, please send this text file to me direct as I can't get
> > attachments from Topica. Thanks.
> >
> > Regards,
> > Mike
>
> Barbarella
> I think you will find that you will have a hard time
> improving the speed of euphoria. If you purchase the source
> code you will find that Rob has hand coded the code to
> obtain the max speed that can be got out of the interpreter
> Any add on will not speed up the code because the overhead
> of the add on will and interfacing will deteriate the any
> speed gain. The only way to increase the speed would be
> to rewrite the complete interpeter into a native compiler
> and this may not gain you that much speed.
> What Euphoria really needs is a better way of interfacing
> to assembler or one of the higher level langauges so
> that it can be easily extended without having rewrite
> the interpeter code.
>
> PS:
> Allot of people on the list will never see your attachments
> unless you use 64 bit text encoding or plain text or post them to
> the archive.
>
> Bernie
>
>
>
>
3. RE: Inner loop compiler
rforno at tutopia.com wrote:
> The attachment was plain text, wasn't it?
I am talking about posting the attachment on the EUFORM
web site because not everyone is subscribed to the receive
junk e-mail from the euform host.
Bernie
4. RE: Inner loop compiler
- Posted by rforno at tutopia.com
Sep 03, 2002
Barbarella:
Of course, the compiler generates assembly or machine code. But to write
such a compiler, you should know assembly coding, maybe much better than if
you were trying to write the routines by hand.
Regarding the examples you gave, I think that only an extremely powerful
optimizing compiler could perform such a kind of analysis. To the best of my
knowledge, C/C++ compilers in existence aren't as efficient as this. So, it
seems that the task in front of us is a very demanding one.
Moreover, with the later processors (486, Pentium), there is no timing
difference for many instruction pairs, like ADD - INC, so that you get the
same timing assuming a non-optimizing C compiler translates i += 1 to ADD
i,1 and i++ to INC i; and the compiler should take into account whether the
program is to be run on an 80386 or a Pentium, for example (remember that
many Euphoria users, like Igor, still use a 386). So, I think the job is
really a big one, maybe an impossible one. Well, "impossible" is maybe too
much, but you know how things are...
Regards.
----- Original Message -----
From: <OthelloVivaldi at hotmail.com>
To: EUforum <EUforum at topica.com>
Sent: Tuesday, September 03, 2002 6:00 PM
Subject: Re: Inner loop compiler
Rforno,
> I'm a bit confused regarding what you are proposing. For
> example, do you think it is possible to write fast compiled
> code without using assembly? If so, how?
Now I'm a bit confused too. It depends on what you mean when you say 'using
assembly'. Some routines might be written by humans, but the entire point
with a compiler is that IT generates the assembly or machine code. To
illustrate this, there are many ways to perform the addition i = i + i on an
x86:
add i, i
or
lea i, [i + i]
or
sal i, 1 -- i.e shl
if the compiler happens to know that i = 1, as would be the case after xor
i, i / inc i, it could also be done by:
inc i
or
add i, 1
or even, if i had just been generated by i = j / 2, where j was even:
mov i, j
Etc. Which one is preferable depends on the context: what flags and
registers will be affected and in what way. How many clocks will it take,
how much memory for the code (the penalty for prefetching must be
considered). The compiler must attempt to pair instructions, avoid agi
stalls whenever possible, avoid too much jumping and unroll small loops if
that improves speed.
Rather than writing thousands of little chunks of assembly, in an attempt to
cover all such possibilities for each source operation, and then concatenate
them according to the directions in the source, I hoped that the compiler
would be able to write it's own code based on it's understanding of
(ideally) single cpu instructions or a few dozen human-made templates
consisting of 1, 2 or maybe 3 instructions, e.g.:
a = b + c
might convert to:
mov a, b
add a, c
or
lea a, [b + c]
or if the compiler knows that b was recently zeroed (e.g. sbb b, b):
add a, c
or, if b happens to be in memory:
add a, [b]
add a, c
or
place b in a reg
add a, b
add a, c
And so on. Any reasonable combination of instructions that are functionally
equivivalent to the source writer, are valid alternatives.
Of course: I'm still not certain how to acutally accomplish all this. It
just seems like the solution must integrate or sum up all the relevant
factors and then evaluate many different ways a program can be written in
order to find the best alternative. I'm hoping an A*-like search could do
this. Do you think it sounds too ambitious?
I have practically no experience with assembly or compilers, but I thought
writing a compiler might give me some experience. After all, such a small
project, basically involving arithmetic, logic and program flow instructions
(what Intel calls application-level-instructions), ought to be a
*comparably* simple task. I repeat: *Comparably*.
> At least, that is what I understood when you say there is
> no need for assembly programmers.
I think I wrote, "you need not be an assembly programmer".
That doesn't exclude assembly programmers, does it? :)
> Regarding some other issues, like rand() or time() routines,
> I could help if needed, at the assembly level.
Great, That is most kind of you!
> By the way, maybe you can explain what is the use Rob assigns to the
> remaining bit of integers (32 bits - 31 bits = 1 bit). If not, maybe Rob
> will do .
The documentation says little about this, but what I'm guessing is that
Euphoria stores it's sequences in dynamic 32 bit strings. One bit of each
int (not necessarily a concretely numbered bit, it could be for example a
combination of the two most significant bits) determine whether an object is
a Euphoria integer or somehting else. If it's an integer, the rest of the
int holds the 31 bit integers value. If it's an atom or a sequence, the rest
of the integer may hold a pointer to the contents of that object, or
something like that.
However, it doesn't matter, since we are not allowed to access Euphoria
objects directly anyway.
Does this clarify anything?
Yours Sincerely,
Barbarella
5. RE: Inner loop compiler
Hello Barbarella,
Here are some more ideas I had on what to implement first in a simple
compiler:
Functions and Procedures. Parameters are passed on the stack, using
push instructions. Space for local variables is created by moving the
stack pointer. Parameters and local variables are accessed by reading
memory at the stack pointer + an offset. Recursion should be allowed -
that's why we have a stack. Function results should be returned in the
eax register. No registers need to be saved before calling subroutines,
but a subroutine may modify any register except the stack pointer.
(Ideas for later implementation: allow complex calling conventions like
passing parameters in registers, store local variables in registers,
etc)
Global Variables. Global variables are simply a pointer to someplace
allocated on the heap. (Variables can be optimized to be stored as
registers later.)
Data Types. Let's stick with 32-bit integers for now. (We can add
floating point and arrays later.) (We could also probably implement
arrays just using peek/poke.)
Simple Assignment and Arithmetic. Assignments will be initially
limited to "x = y" where y is another variable or a literal value.
Arithmetic can only be done on existing variables, in the form "x += y".
(We can add more arithmetic operations later.)
If and While statements. Each statement may have only one
comparision. Comparisons can have the form "x < y" where x or y may be
a variable or a literal value. (For loops can be implemented using
while loops. From what I've heard, the first versions of Euphoria
didn't have for loops for that reason.)
This seems like a good place to start. Not too complicated, but
powerful enough to do some simple tasks.
Now, for the intermediate representation, a tree structure would
probably be appropriate. The parser would take the text representation
of the program (the source code) and convert it to an intermediate
representation. This intermediate representation is where the
optimization would take place, but we'll leave that out for now. Then
the code generation would use the optimized intermediate representation
to create the actual machine code.
Each statement is a sequence. A block of code will be a sequence of
statements. Statement sequences may contain expression sequences as
well. (David Cuny loves stuff like this.)
Here's an example:
--> {
x = 1 --> {"assign", "x", {"literal", 1}},
y = x --> {"assign", "y", {"var", "x"}},
if y = 2 then --> {"if", {"equal", {"var", "y"}, {"literal", 2}},{
y += 1 --> {"addto", "y", {"literal", 1}}
else --> },{
y = 0 --> {"assign", "y", {"literal", 0}}
end if --> }}
--> }
The code example is stupid, but I hope it illustrates how the
translation process works. Each statement sequence has what kind of
statement as its first element ("assign", "if", "addto", etc).
Expression statements work the same way ("literal", "var", "equal"). We
could have taken a shortcut for expressions and left off the literal/var
part, but this way we'll be able to produce more complex expressions
later, like: {"+", {"*", {"literal", 5}, {"var "y"}}, {"var", "x"}}
which is "5 * y + x"
Here's the assembly code representations for the statements I think
we'll need:
(local) (global)
x = y
mov eax, [esp-@y] mov eax, [@y]
mov [esp-@x], eax mov [@x], eax
x = c
mov [esp-@x], c mov [@x], c
poke4(x, y)
mov eax, [esp-@y] mov eax, [@y]
mov ebx, [esp-@x] mov ebx, [@x]
mov [ebx], eax mov [ebx], eax
poke4(x, c)
mov ebx, [esp-@x] mov ebx, [@x]
mov [ebx], c mov [ebx], c
poke4(c, y)
mov eax, [esp-@y] mov eax, [@y]
mov [c], eax mov [c], eax
poke4(c1, c2)
mov [c1], c2
x = peek4(c)
mov eax, [c] mov eax, [c]
mov [esp-@x], eax mov [@x], eax
x = peek4(y)
mov ebx, [esp-@y] mov ebx, [@y]
mov eax, [ebx] mov eax, [ebx]
mov [esp-@x], eax mov [@x], eax
x += c
add [esp-@x], c add [@x], c
x += y
mov eax, [esp-@y] mov eax, [@y]
add [esp-@x], eax add [@x], eax
proc(...)
push ...
call proc
add esp, #args
x = func(...)
push ...
call func
add esp, #args
mov [esp-@x], eax mov [@x], eax
return x
mov eax, [esp-@x] mov eax, [@x]
ret
return c
mov eax, c
ret
while x OP c do
cmp [esp-@x], c cmp [@x], c
jnOP end
top:
...
cmp [esp-@x], c cmp [@x], c
jOP top
end:
while x OP y do
mov eax, [esp-@y] mov eax, [@y]
cmp [esp-@x], eax cmp [@x], eax
[as above]
if x OP y then ... else ... end if
mov eax, [esp-@y] mov eax, [@y]
cmp [esp-@x], eax cmp [@x], eax
jnOP else
...
jmp end
else:
...
end:
Comments? Suggestions? Clarifications?
Or "shut up man and start coding"? 
Pete
6. RE: Inner loop compiler
> -----Original Message-----
> From: Pete E [mailto:xseal at harborside.com]
> Now, for the intermediate representation, a tree structure would
> probably be appropriate.
> Here's an example:
>
> --> {
> x = 1 --> {"assign", "x", {"literal", 1}},
> y = x --> {"assign", "y", {"var", "x"}},
> if y = 2 then --> {"if", {"equal", {"var", "y"}, {"literal", 2}},{
> y += 1 --> {"addto", "y", {"literal", 1}}
> else --> },{
> y = 0 --> {"assign", "y", {"literal", 0}}
> end if --> }}
> --> }
> We
> could have taken a shortcut for expressions and left off the
> literal/var
> part, but this way we'll be able to produce more complex expressions
> later, like: {"+", {"*", {"literal", 5}, {"var "y"}}, {"var", "x"}}
> which is "5 * y + x"
This is exactly the approach I took for matheval (the most current code out
there is actually contained in EuSQL, which uses matheval). You could look
at parseval.e. It may not be the *best* way to implement this, but it is
easily extendible. It would need some adjustment to work for this, however,
since it assumes that everything should be one giant expression, so it ends
up multiplying everything together when there is nothing else to do--which
is just what you'd expect for math:
(x+y)(x+y) => (x+y) * (x+y)
All you'd really have to do is take that part out. Basically, it scans the
input, and turns things into tokens. Each token has a precedence, which
establishes the order in which things should be done (i.e., multiply before
you add). Based on the precedence, tokens are 'collapsed':
"(x + 1)^2" =>
{ '(', {var,"x",{1}}, {add,{},{}}, {constant,{1},{}}, ')', {exponent,{},{}},
{constant,{2},{}} =>
{ '(', {add,{var,"x",{1}},{constant,{1},{}}}, ')', {exponent,{},{}},
{constant,{2},{}} =>
{exponent,{add,{var,"x",{1}},{constant,{1},{}}}, {constant,{2},{}} } =>
{exponent,
{add,
{var,"x",{1}},
{constant,{1},{}}},
{constant,{2},{}} }
Parseval.e basically shows you what you need to do to set up your tokens.
resolve_math_func() is a way for files to get the proper id for math
functions in the library. reg_parse_func() tells parseval.e what to do
about a new token, and supplies the routine id for the function that will
actually 'collapse' the token. This is where error checking is done. If
you're interested, I'd be happy to answer any questions you have.
BTW, you can d/l EuSQL at
http://www14.brinkster.com/matthewlewis/projects.html
Matt Lewis
7. RE: Inner loop compiler
Matthew Lewis wrote:
> This is exactly the approach I took for matheval (the most current code
> out
> there is actually contained in EuSQL, which uses matheval). You could
> look
> at parseval.e. It may not be the *best* way to implement this, but it
> is
> easily extendible. It would need some adjustment to work for this,
> however,
> since it assumes that everything should be one giant expression, so it
> ends
> up multiplying everything together when there is nothing else to
> do--which
> is just what you'd expect for math:
>
> (x+y)(x+y) => (x+y) * (x+y)
>
> All you'd really have to do is take that part out. Basically, it scans
> the
> input, and turns things into tokens. Each token has a precedence, which
> establishes the order in which things should be done (i.e., multiply
> before
> you add). Based on the precedence, tokens are 'collapsed':
>
> "(x + 1)^2" =>
> { '(', {var,"x",{1}}, {add,{},{}}, {constant,{1},{}}, ')',
> {exponent,{},{}},
> {constant,{2},{}} =>
> { '(', {add,{var,"x",{1}},{constant,{1},{}}}, ')', {exponent,{},{}},
> {constant,{2},{}} =>
> {exponent,{add,{var,"x",{1}},{constant,{1},{}}}, {constant,{2},{}} } =>
>
> {exponent,
> {add,
> {var,"x",{1}},
> {constant,{1},{}}},
> {constant,{2},{}} }
This collapse technique looks useful for an optimization phase. The
parsers I've written already handle operator precedence for arithmetic
expressions.
> Parseval.e basically shows you what you need to do to set up your
> tokens.
> resolve_math_func() is a way for files to get the proper id for math
> functions in the library. reg_parse_func() tells parseval.e what to do
> about a new token, and supplies the routine id for the function that
> will
> actually 'collapse' the token. This is where error checking is done.
> If
> you're interested, I'd be happy to answer any questions you have.
>
> BTW, you can d/l EuSQL at
> http://www14.brinkster.com/matthewlewis/projects.html
>
> Matt Lewis
The thing I haven't figured out how to do yet is convert the nested
expression into a flat instruction sequence. Some temporary storage
will always be required.
Say you have the expression: a * b + x * y
The intermediate form is:
{add,
{mul, {var, "a"}, {var, "b"},
{mul, {var, "x"}, {var, "y"}
}
The simpleton compiler might try to do this:
mov eax, [@a]
mul eax, [@b]
mov eax, [@x]
mul eax, [@y]
add eax, eax
A smarter compiler might try to use a second register, but what happens
when you run out of registers for a complex expression... the stack
will have to used somehow. Maybe some temporary variables can be
inserted by the parser when it sees a complicated expression... and let
the optimizer substitute registers for the temp variables.
I also found some other examples of run-time assemblers and mathematical
compilers here:
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=COTD-ExpressionCompiler&forum=cotd&id=-1
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=COTD-SoftWire&forum=cotd&id=-1
Pete
8. RE: Inner loop compiler
- Posted by kbochert at copper.net
Sep 05, 2002
-------Phoenix-Boundary-07081998-
Hi Pete E,
If you're into fast assembly code you might check out
http://www.agner.org/assem/
Karl Bochert
-------Phoenix-Boundary-07081998---
9. RE: Inner loop compiler
Hi Karl,
I'm definitely into fast assembly. Thanks for the link!
Here's another good site:
http://www.azillionmonkeys.com/qed/asm.html
Pete
kbochert at copper.net wrote:
> Hi Pete E,
>
> If you're into fast assembly code you might check out
> http://www.agner.org/assem/
>
> Karl Bochert
10. RE: Inner loop compiler
> -----Original Message-----
> From: Pete E [mailto:xseal at harborside.com]
> The thing I haven't figured out how to do yet is convert the nested
> expression into a flat instruction sequence. Some temporary storage
> will always be required.
<SNIP>
> A smarter compiler might try to use a second register, but
> what happens
> when you run out of registers for a complex expression... the stack
> will have to used somehow. Maybe some temporary variables can be
> inserted by the parser when it sees a complicated
> expression... and let
> the optimizer substitute registers for the temp variables.
You will probably rarely need very many registers/temp vars. I'm not sure
there's any easy way to compute the exact number you'd need for any
expression, but here's a way to bound the problem as far as you'll probably
need:
Assume that you've turned the expression into a sequence tree, and we've got
all binary expressions. The worst case most storage needed) is if you have
a 'full' tree. If you diagram the expression like a tree, then all nodes
have 2 branches, down to the lowest level. Each node is actually a binary
operator. You'll have (2^n)-1 nodes, and you'll need a total of n+1 storage
locations. This includes using eax.
Now, count the deepest level of nesting. Call this number L. You can
compare this to n to get an idea about how many you'll need. The higher L
goes, the fewer storage locations you'll need based on the node count, since
to fill out an L-level tree, you'd need (2^L)-1 nodes. In a very filled out
tree, the numbers will be close. You can see that each level is
successively harder to reach, since each node corresponds to an operator,
and the number of nodes required increases exponentially, meaning that in
order to need 6 storage locations, you'd need at least 127 nodes/operators!
Most expressions will be a lot simpler than this. For example, suppose you
had an expression with a thousand additions. If you simply 'string' them
along one branch of the tree, you'll only need one register, but if you
decide to nest them all evenly, you'll need some temporary storage. You'll
never need more than 3 locations (i.e., eax/ecx/edx) for an expression with
up to 14 operators (or, 4 registers will get you up to 30 operators per
expression). That seems like a pretty reasonable limit to me. If the user
tries more than that, give an error ("ERROR: Expression too complex--too
many operators"). Of course, you could really handle more than that,
assuming that you don't have a full tree.
To unwind the nested sequences, you just have to start from the most deeply
nested part and work your way back. At each stage, go down the 'sibling'
branch, storing any result in a temporary location. Keep track of how many
temporary slots you're using. Eventually, you get to the top of the tree
and are only using eax.
Matt Lewis
11. RE: Inner loop compiler
OthelloVivaldi at hotmail.com wrote:
> However, it would be a problem if people found themselves 'forced' to
> use peek and poke on a regular basis. That would compromise safety. One
> possibility is to adopt a safe version of the c pointer type. Such a
> pointer could either address an array that was safely allocated by
> Euphoria, or an area of memory (say, bios video memory) that the
> programmer would want to access. Unlike in c, the pointer would not be
> allowed to be misaligned with its type or moved out of it's own bounds.
> E.g. :
>
> -- Integer 'video_mem' is allowed to point to any byte in the mode 19
> screen.
> BYTE POINTER video_mem 0xA0000, 64000
Pointer type-safety.... ah, one of the reasons I like Ada.
Well, I wasn't saying that I would force programmers to use peek/poke
for arrays, just that arrays can be accessed using peek/poke. The
compiler could tranlate array accesses to a peek/poke, throw in a
'bound' instruction for range checking, and a 'test' instruction for
alignment. There is a caveat with 'bound' though - the upper and lower
bounds must be stored in two adjacent memory locations and the location
pointer is the second argument to the bound instruction (I think)
Somewhere asm.e zip files have bound.ex which tests this.
> Actually, I was thinking in the opposite direction of Euphoria's
> arbitrarily structured sequences. Sequence trees with recursive pointers
> are great in high level, but in the inner loop, I'd like to sacrifice
> this kind of flexibility and instead go for fast, direct indexing.
> Something like arrays of (preferably) power-of-2 aligned data, e.g. int
> a[17][512] would be great. Of course, sometimes arrays like [600][800]
> might also be nice, (to save memory), which could hopefully be arranged
> for with a few lea operations. Your own mode 19 pixel(x,y) in asm.ex, is
> an example.
Yes, I had forgotten about that. I had some code somewhere that would
calculate the fewest lea instructions to perform some arbitrary constant
multiply and add, but in most complex cases I would expect a straight
mul to use fewer clocks on most processors.
> But what happens if a program runs out of stack memory at run-time?
Oops.. I read your statement in your next email about stack overflow as
arithmetic overflow.
But here's what happens:
On Linux you get "Segmentation fault"
On DOS you get a frozen computer
On Windows you get a blue screen of death or "This application has
performed an illegal operation" and will be sent to jail, do not pass
go, do not collect $200.
Traditionally, the stack resides at the top of the 'heap' memory space.
The heap grows upward and the stack grows downward to meet each other
somewhere in the middle. The stack overflows when the stack pointer
crosses the upper heap bound.
I don't know what happens with memory paging architectures. I would
guess that when you try to access stack space on a new virtual memory
page, the kernel would just give you a new page and write the older
pages out to the pagefile. Or this could just be wishful thinking.
Depends on the OS.
> But Bernie says that Rob Craig is 'hand coding' some of his routines,
> does this mean Eu runs only on x86?
As far as I know yes, only x86. I would love to see Eu on Sparc and
MIPS and maybe PowerPC though. If Rob were interested in having me port
the hidden parts of the sequence engine to those architectures (I have
access to each at work) and creating arch-specific libraries for the
Eu-to-C translator, I would gladly do it. However intellectual property
rights restrictions would prevent me from legally doing so.
> Finally I'd like to give a general outline of my plans for a compiler
> based on the a-star algorithm. I hope to be able to write a much better
> and more detailed description later.
> <snip>
This sounds awesome! The only thing I would add is some real-time
performance evaluator to check the actual speed of the code generated,
and tune the values of the instruction costs based on the ability of the
processor. This would remove the need to diddle the numbers so much,
and the code generator could adapt to newer processor chips that have
different clocks for various instructions.
I've wanted to write a compiler like this for a long time.
Pete
12. RE: Inner loop compiler
rforno at tutopia.com wrote:
> Barbarella:
> Perhaps you should emphasize the "may" in "may be impossible". It also
> "may
etc etc >
Why are you all trying to reinvent the wheel and missing
the point of the real challange.
I think that it would be a better idea to use the many
assemblers/compilers out there that are fully able to do a good
job of optimising code, to generate a object module.
Then the challange is to find a easy way to embed or
interface that object code into Euphoria.
Bernie
13. RE: Inner loop compiler
Hi Barbarella,
> Hi, Everybody!
>
> Are anyone here interested in looking into the possibilities
> of a minimalist, compiled machine oriented language to be used
> with Euphoria?
Yes, although the Euphoric it is the better I say.
> I would like the language to generate small routines that could
> interface with Euphoria and speed up the inner loops of programs.
> I would prefer to give safety, speed and simple design priority.
>
> I've attached a zipped text file that describes my ideas in a
> little bit more detail. Please remember it's just unclear
> thoughts so far, much have yet to be worked out.
>
> It would extremely nice to hear your opinion!
>
>
> Yours Sincerely,
> Barbarella
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.
Oh, by the way, please send this text file to me direct as I can't get
attachments from Topica. Thanks.
Regards,
Mike
14. RE: Inner loop compiler
Mike wrote:
> Hi Barbarella,
>
> > Hi, Everybody!
> >
> > Are anyone here interested in looking into the possibilities
> > of a minimalist, compiled machine oriented language to be used
> > with Euphoria?
> Oh, by the way, please send this text file to me direct as I can't get
> attachments from Topica. Thanks.
>
> Regards,
> Mike
Barbarella
I think you will find that you will have a hard time
improving the speed of euphoria. If you purchase the source
code you will find that Rob has hand coded the code to
obtain the max speed that can be got out of the interpreter
Any add on will not speed up the code because the overhead
of the add on will and interfacing will deteriate the any
speed gain. The only way to increase the speed would be
to rewrite the complete interpeter into a native compiler
and this may not gain you that much speed.
What Euphoria really needs is a better way of interfacing
to assembler or one of the higher level langauges so
that it can be easily extended without having rewrite
the interpeter code.
PS:
Allot of people on the list will never see your attachments
unless you use 64 bit text encoding or plain text or post them to
the archive.
Bernie
