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
|
Not Categorized, Please Help
|
|
