1. pointers to variables
- Posted by Lnettnay Aug 01, 2009
- 1224 views
Hi, all. I have returned to Euphoria after seven years of being distracted. Got to say I am thrilled by what has progressed in my absence! v2.1 was the big one back then.
Here's something I always wanted: direct access to the contents of Euphoria variables from within my assembly routines. Peeks and pokes are fine for shuffling small quantities of data back and forth but dent assembly performance with large data sets as they are (relative to assembler) quite slow, even with sequence operations. I think the good way to do this would be with a function to return the memory address of a Euphoria object that the assembly code could read or write directly. (who remembers the varptr() function from good ol` Basic?)
IIRC there is a suggestion that a function such as var_id() may be introduced. A further refinement to this may be along the lines of pointer = get_var_address(var_id(myvar)).
That's all I would need or want - just the pointer.
Now I believe that the memory representation of Euphoria objects would be quite complicated and any assembler code that deals with such may be difficult but this is something I think I can deal with.
I think it would be the responsibility of the assembler writer to untangle/reentangle sequences. Perhaps only the very ambitious would construct deeply nested sequences from within asm to return to Euphoria. In fact, it may well not be possible to create new or enlarge existing sequences from within assembly given just a pointer but this would not make it any less useful.
What exactly do I want to do? Okay, here's an example. Say I have generated a floating point fractal bitmap image in memory using an assembly language routine (which I intend to do). I now want to bring this structure into Euphoria to determine it's Lyapunov exponent. The traditional method would appear to involve many, many thousands of individual peek() and float64_to_atom() statements, not a fast operation. (in early code I tried this and found the data transfer took longer than generating the fractal in the first place!) The pointer method would require the asm routine to write values directly into a preallocated one-dimensional sequence which would be immediately ready for use.
Would anyone else find a use for this? Is there a better way I am overlooking? I have many questions, Mr Sparkle.
Nick Metcalfe
2. Re: pointers to variables
- Posted by LarryMiller Aug 01, 2009
- 1255 views
Welcome back to Euphoria. I am sure that many on this forum would see the lack of pointers as a major advantage. Pointers would certainly simplify some applications but have some serious problems, not the least of them being the great possibility for abuse. A high level language like Euphoria isolates the value of a variable from it's physical representation. This allows the interpreter to change either the address of a variable or how it is internally represented. If Euphoria allowed pointers to variables this flexibility would be lost. There is also the possibility that some details of internal representation may change in future versions. This would break any application that used pointers.
I believe that interfacing to C and assembly can, and should be, improved. At present there is no concensus on how this can best be accomplished. But pointers are not the best way to do this.
Do feel free to suggest any other improvements to the language.
3. Re: pointers to variables
- Posted by mattlewis (admin) Aug 01, 2009
- 1275 views
Hi, all. I have returned to Euphoria after seven years of being distracted. Got to say I am thrilled by what has progressed in my absence! v2.1 was the big one back then.
Here's something I always wanted: direct access to the contents of Euphoria variables from within my assembly routines. Peeks and pokes are fine for shuffling small quantities of data back and forth but dent assembly performance with large data sets as they are (relative to assembler) quite slow, even with sequence operations. I think the good way to do this would be with a function to return the memory address of a Euphoria object that the assembly code could read or write directly. (who remembers the varptr() function from good ol` Basic?)
This is possible. If you're calling your routines via c_func/proc, use the E_* data types when defining them. The parameters will be passed with the 'raw' object values. The original use for this was for calling euphoria translated dlls, but you can use it in other ways. In wxEuphoria, for example, I directly manipulate euphoria objects using C.
IIRC there is a suggestion that a function such as var_id() may be introduced. A further refinement to this may be along the lines of pointer = get_var_address(var_id(myvar)).
That's all I would need or want - just the pointer.
Yes, var_id() has been proposed. This might still happen in a future release, but not for 4.0. I doubt that the raw object value will be exposed, however.
Matt
4. Re: pointers to variables
- Posted by prickle Aug 01, 2009
- 1218 views
Welcome back to Euphoria. I am sure that many on this forum would see the lack of pointers as a major advantage. Pointers would certainly simplify some applications but have some serious problems, not the least of them being the great possibility for abuse. A high level language like Euphoria isolates the value of a variable from it's physical representation. This allows the interpreter to change either the address of a variable or how it is internally represented. If Euphoria allowed pointers to variables this flexibility would be lost. There is also the possibility that some details of internal representation may change in future versions. This would break any application that used pointers.
I believe that interfacing to C and assembly can, and should be, improved. At present there is no concensus on how this can best be accomplished. But pointers are not the best way to do this.
Do feel free to suggest any other improvements to the language.
Thanks, Larry. Yes of course you are quite right. Pointers in the style of C are nasty things that mainly serve to confuse programs and programmers. Nevertheless, this is what allocate() returns, a pointer to a block of memory. Pointers to variables appeared to complement this scheme and seemed the most direct route to an (elegant? at least in the spirit of what I am trying to do) solution for me, but by no means the best. Have any other mechanisms been suggested to allow this kind of thing?
This is possible. If you're calling your routines via c_func/proc, use the E_* data types when defining them. The parameters will be passed with the 'raw' object values. The original use for this was for calling euphoria translated dlls, but you can use it in other ways. In wxEuphoria, for example, I directly manipulate euphoria objects using C.
Hi Matt. Yes, I did consider such a method, but thought it could be quite complex. Let's see if I understand correctly.
- I would need to allocate a block of memory
- poke in a preamble to set up/access the stack frame? if required.
- poke in my code from the mini-assembler, including (hard)code to access E_* data types.
- poke in more code afterwards to tidy up and return the new E_* object
- feed the address of the block into define_c_func along with parameter info
- cross fingers and use c_func to call the routine
Would it work? what have I forgotten?
This still would not protect me from object implementation changes in new forms of Euphoria as I could not get at the E_* data type declarations from the mini-assembler and any accesses to the type would need hard-coded parameters.
But it occurs to me that this would be the case anyway with a dll/so and therefore hesitantly conclude the E_* data type is a fixed representation of an object that the interpreter probably does not use internally. Please correct me if this is not the case.
Has anybody tried constructing a dll/so in memory like this? It occurs to me this method would be made simpler by using an external assembler like MASM or such to build a proper dll/so from the source, and then simply treat it like any other shared library. This is not what I want, Towing a heavy full-featured macro assembler behind what should be a fast, lightweight include file or requiring it as a dependency is too ugly.
Cheers, Nick
5. Re: pointers to variables
- Posted by mattlewis (admin) Aug 02, 2009
- 1199 views
This is possible. If you're calling your routines via c_func/proc, use the E_* data types when defining them. The parameters will be passed with the 'raw' object values. The original use for this was for calling euphoria translated dlls, but you can use it in other ways. In wxEuphoria, for example, I directly manipulate euphoria objects using C.
Hi Matt. Yes, I did consider such a method, but thought it could be quite complex. Let's see if I understand correctly.
- I would need to allocate a block of memory
- poke in a preamble to set up/access the stack frame? if required.
- poke in my code from the mini-assembler, including (hard)code to access E_* data types.
- poke in more code afterwards to tidy up and return the new E_* object
- feed the address of the block into define_c_func along with parameter info
- cross fingers and use c_func to call the routine
Would it work? what have I forgotten?
Yes, you'll need to make sure you deal with the stack correctly. This depends on your calling convention, and whether you use any. If you use cdecl, you won't need to clean up the arguments that were passed on the stack. Once you have your code poked into memory:
constant my_asm = define_c_func( "", {"+", my_asm_ptr}, {E_OBJECT}, C_INT )
The above would set up a handle for using c_func() to call your asm that took a euphoria object as a parameter and returned an int. There's really no finger crossing required. 
This still would not protect me from object implementation changes in new forms of Euphoria as I could not get at the E_* data type declarations from the mini-assembler and any accesses to the type would need hard-coded parameters.
You'll still be vulnerable to changes in the representation, though I don't think there's a terribly large risk here. At least not from reading. The structure has changed for 4.0, but you don't really need to worry unless you're allocating new objects. So the euphoria ABI, at least with respect to native data types has changed somewhat, but is also backwards compatible, at least for reading. We've added a pointer to the structure, which is usually null, but if not, tells euphoria how to manage auto-cleanup for the object.
I had to update wxEuphoria, which is written in C, and manipulates native euphoria data. The change was 2 or 3 lines, and now it works with both 3.1 and 4.0.
But it occurs to me that this would be the case anyway with a dll/so and therefore hesitantly conclude the E_* data type is a fixed representation of an object that the interpreter probably does not use internally. Please correct me if this is not the case.
I'm not sure what you're saying here. Euphoria objects take three forms:
- 31 bit integers
- doubles
- sequences
31-bit integers are what they are. The other two are actually structures, and the pointer is shifted, with a mask applied to indicate whether it points to a sequence or a double (atom). This requires that the pointers are 8-byte aligned. Take a look at execute.h for the details. And please ask any questions you might have about how to use them.
Has anybody tried constructing a dll/so in memory like this? It occurs to me this method would be made simpler by using an external assembler like MASM or such to build a proper dll/so from the source, and then simply treat it like any other shared library. This is not what I want, Towing a heavy full-featured macro assembler behind what should be a fast, lightweight include file or requiring it as a dependency is too ugly.
I have done this before (though it was a while ago, and I don't have the source any more). The biggest hurdle for me is just writing the assembly code.
Matt
6. Re: pointers to variables
- Posted by prickle Aug 02, 2009
- 1205 views
Yes, you'll need to make sure you deal with the stack correctly. This depends on your calling convention, and whether you use any. If you use cdecl, you won't need to clean up the arguments that were passed on the stack. Once you have your code poked into memory:
constant my_asm = define_c_func( "", {"+", my_asm_ptr}, {E_OBJECT}, C_INT )
The above would set up a handle for using c_func() to call your asm that took a euphoria object as a parameter and returned an int. There's really no finger crossing required.
I have done this before (though it was a while ago, and I don't have the source any more). The biggest hurdle for me is just writing the assembly code.
Matt
Fabulous. Thanks heaps Matt. This is the method I will pursue. As far as the assembly is concerned, I do not expect to write much either, or rather write it all up front 
. I intend to bring my JIT compiler up to date. At the moment, it is not much more than a dynamic expression evaluator that compiles to x86 FPU mnemonics. I would like to bring it up to a standard comparable to GNU Lightning or PyCORE to make it more generally useful to people other than me.
It needs better variable handling and more general purpose statements to make it an actual language. The code it generates is by no means optimal but it tries to minimise loads and stores by evaluating as much as possible using the FPU's own stack. I also wish to support MMX, SSE and the upcoming AVX SIMD architectures.
Don't expect anything soon of course. The codebase for the expression evaluator is ugly, dusty and looks completely alien to me despite the fact I wrote it. It's resurrection is currently still in the planning stage.
The evaluator was primarily used to build the NickFrac screen saver. Kind of defeated the purpose, maxxing out the FPU in spikes of activity while spending most of the time waiting for pixels to be shuffled into Windows' GDI. The DOS version of the screensaver (unreleased) runs full speed though. The evaluator is currently for asm users, as activities like looping still need hand coded x86. It is undocumented, unwieldy and unfinished which is why I never released.
It may be appropriate to start a new thread in order to invite discussion on this matter. I believe I have demonstrated the efficacy of this method as a way of bringing real performance to Euphoria with a high-level language model. The possible benefits of a full function JIT compiler for Euphoria would appear to extend far beyond my own goal, a proper fractal explorer.
Is this the kind of thing people want, or is it just me?
Nick
7. Re: pointers to variables
- Posted by bernie Aug 02, 2009
- 1218 views
I already have dynamic assembler working on Euphoria.
All I want is call_backs to work in DOS.
8. Re: pointers to variables
- Posted by prickle Aug 02, 2009
- 1198 views
I already have dynamic assembler working on Euphoria.
All I want is call_backs to work in DOS.
Really? Can you tell me anything more about it? is it just an assembler?
9. Re: pointers to variables
- Posted by bernie Aug 02, 2009
- 1178 views
I already have dynamic assembler working on Euphoria.
All I want is call_backs to work in DOS.
Really? Can you tell me anything more about it? is it just an assembler?
This is a sample of how you can write assembler code in ver 4.0
of Euphoria with my include file.
I just would like to be able to do call_backs in DOS.
export function strlen(atom str) -- tested Asm("strlen_", "prolog4eu "& "cld "& "mov edi, [ebp+8] "& "xor eax, eax "& "or ecx, -1 "& "repne scasb "& "not ecx "& "dec ecx "& "mov eax, ecx "& "epilog4eu "& "ret 0 ",1,u) return f("strlen_",{str}) end function -- export function strspn(atom str1, atom str2) -- tested Asm("strspn_", "prolog4eu "& "cld "& "xor eax, eax "& "mov ecx, [ebp+8] "& "jmp ssp004 "& "ssp001: "& "inc ecx "& "mov edi, [ebp+12] "& "ssp002: "& "mov dh, [edi] "& "or dh, dh "& "jz ssp005 "& "cmp dl, dh "& "je ssp003 "& "inc edi "& "jmp ssp002 "& "ssp003: "& "inc eax "& "ssp004: "& "mov dl, [ecx] "& "or dl, dl "& "jnz ssp001 "& "ssp005: "& "epilog4eu "& "ret 0 ",2,u) return f("strspn_",{str1,str2}) end function -- export function strpbrk(atom str1, atom str2) -- tested Asm("strpbrk_", "prolog4eu "& "cld "& "mov eax, [ebp+8] "& "jmp sb004 "& "sb001: "& "mov ecx, [ebp+12] "& "sb002: "& "mov dh, [ecx] "& "or dh, dh "& "jz sb003 "& "cmp dl, dh "& "je sb005 "& "inc ecx "& "jmp sb002 "& "sb003: "& "inc eax "& "sb004: "& "mov dl, [eax] "& "or dl, dl "& "jnz sb001 "& "xor eax, eax "& "sb005: "& "epilog4eu "& "ret 0 ",2,u) return f("strpbrk_",{str1,str2}) end function -- export function strtok(atom buff, atom delim) -- tested Asm("strtok_", "prolog4eu "& -- -- "mov esi, [ebp+8] "& -- get buffer "test esi esi "& -- first call ? "jz nexttok "& -- no "mov [@ptr], esi "& -- save buffer "nexttok: "& -- "mov edi, [ebp+12] "& -- yes get delimit "mov esi, [@ptr] "& -- get current ptr "cmp esi, 0 "& -- "je near endtok "& -- bail out "push edi "& -- delimit "push esi "& -- buffer "mov eax, "&AGet("strspn")& -- << ---- << THIS IS A CALL BACK "call near eax "& -- find start of token "add [@ptr], eax "& -- goto first token "mov edi, [ebp+12] "& -- get delimit "mov esi, [@ptr] "& -- get current ptr "cmp esi, 0 "& -- "je near endtok "& -- bail out "cmp [esi], 0 "& -- pointing to zero ? "je near endtok "& -- bail out "push edi "& -- delimit "push esi "& -- buffer "mov eax, "&AGet("strpbrk")& -- << ---- << THIS IS A CALL BACK "call near eax "& -- find the end of the token "mov esi, [@ptr] "& -- get current ptr "cmp eax, esi "& -- "je near endtok "& -- "cmp eax, 0 "& -- "je exact "& -- "mov [@ptr], eax "& -- "mov edi, eax "& -- "mov eax, 0 "& -- "mov [edi], al "& -- "mov eax, esi "& -- "add [@ptr], 1 "& -- "epilog4eu "& -- "ret 0 "& -- "exact: "& -- "mov esi, [@ptr] "& -- get current ptr "push esi "& -- "mov eax, "&AGet("strlen")& -- << ---- << THIS IS A CALL BACK "call near eax "& -- "cmp eax, 0 "& -- "jne lasttok "& -- "jmp endtok "& -- "lasttok: "& -- "mov ecx, 0 "& -- "mov eax, [@ptr] "& -- get current ptr "mov [@ptr], ecx "& -- block next call "epilog4eu "& -- "ret 0 "& -- "endtok: "& -- "mov eax, 0 "& -- "epilog4eu "& -- "ret 0 "& -- "ptr: dd 0 ",2,u) return f("strtok_",{buff,delim}) end function
10. Re: pointers to variables
- Posted by prickle Aug 02, 2009
- 1181 views
Sweet. Looks like I got my back end. Supports all them new SIMD x86 opcodes I expect.
I won't want it for a while. Sounds like it's still in active development anyway.
So people like me are execution-time performance junkies. It strikes me that most Euphorians are probably attracted more by development-time performance and ease. I like this too. I think I know how to combine both and make assembled power easily available to the whole Euphoria community.
Currently, the core of the evaluator works like this fragment:
var = --fractal type variable declarations "real a , b , c , d \n"& "real x, y, z, old_x, old_y, old_z \n" & "real temp_x, temp_y, temp_z \n"& "int maxint = 255 \n" vars = read_variables(var) op = --Hopalong fractal iteration parse("temp_x = old_x + d : y = a - old_x")& "fld qword ptr[old_x] " & "ftst " & "fstsw ax " & "fstp st(0) " & "sahf " & "ja hopper_pos " & parse("x = old_y + sqrt(abs(b * temp_x - c))") & --on negative old_x "jmp hopper_done " & "hopper_pos: " & parse("x = old_y - sqrt(abs(b * temp_x - c))") & --on positive old_x "hopper_done: " bits = get_asm(op) --Everything else...
As you can see at the moment it is not much more than a asm writer's convenience, it only handles math and simple vars. Logic and flow are still hand crafted. I have made a syntax that already differs from Euphoria despite the fact the evaluator has no statements! This will change, I expect it should be made at least superficially similar to a subset of Euphoria's own syntax and should definitely not require any raw x86 ops.
I would appreciate any comment on this.
Cheers, Nick.
11. Re: pointers to variables
- Posted by bernie Aug 02, 2009
- 1174 views
Nick:
I am afraid that I can't comment on your code because
I am not much of a mathematician or expert in complex math.
I took a look your fastfill in the archive and complex math in
the archive.
As you look at my code; keep in mind the routines are compile as
you declare and define them. You do not have to think about
poking stuff into the sequence. You just have to pass the parameters to the routine.
If you have three parameters:
function foo(atom parm1, atom parm2, atom parm3) You accesss them in your Asm code in the function like this: Asm("foo_", "mov eax, [ebp+08] "& -- param3 "mov ebx, [ebp+12] "& -- param2 "mov ecx, [ebp+16] "& -- param1
12. Re: pointers to variables
- Posted by prickle Aug 03, 2009
- 1189 views
Nick:
I am afraid that I can't comment on your code because
I am not much of a mathematician or expert in complex math.
Sorry for the poor example. I simply wanted to draw attention to the parse() method which compiles high-level expressions like "a = b * c" into corresponding FPU opcodes to be embedded directly into any assembler. The expression evaluator is complete and has more basic math functions than Euphoria itself (like sgn(), atan2(x,x) and more) but only handles simple variables and has no statements of any kind. It is currently just an interface to simplify FPU programming.
I took a look your fastfill in the archive and complex math in
the archive.
Ugh. I was young and foolish then. Pay no regard to the man behind the curtain.
As you look at my code; keep in mind the routines are compile as
you declare and define them. You do not have to think about
poking stuff into the sequence. You just have to pass the parameters to the routine.
I see this. In fact this feature will probably be quite useful to me.
If you have three parameters:
function foo(atom parm1, atom parm2, atom parm3) You accesss them in your Asm code in the function like this: Asm("foo_", "mov eax, [ebp+08] "& -- param3 "mov ebx, [ebp+12] "& -- param2 "mov ecx, [ebp+16] "& -- param1
Very good. These base pointer offsets will end up hidden in my compiler's symbol table never to be seen again .
Now the questions - Does it support SSE4? what are the maximum number of args? are the base pointer offsets data dependent? are they always the same for the corresponding parameter? (I expect yes) The method you use for returning objects is not clear to me. Could you please elaborate?
Thanks Bernie.
Nick
13. Re: pointers to variables
- Posted by mic_ Aug 03, 2009
- 1161 views
Semi-related to this, fractal computations seem like something that the GPU is highly suitable for. As an example, here's how you could render a static Mandelbrot set using a GLSL shader:
without warning include eugl.ew constant texID = allocate(4) atom theta, lastTime atom program, fragmentShader, vertexShader atom mytexture, twist constant fragmentShaderCode = "void main() {\n"& "vec2 c,z;\n"& "float x0,y0,i;\n"& "z = vec2(0.0, 0.0);\n"& "x0 = gl_FragCoord.x/320.0 - 1.0;\n"& "y0 = gl_FragCoord.y/240.0 - 1.0;\n"& "c = vec2(x0, y0);\n"& "i = 0.0;\n"& "while (true) {\n"& " if (length(z) > 2.0) break;\n"& " z = vec2(x0 + z.x*z.x - z.y*z.y + x0, y0 + z.x*z.y*2.0);\n"& " i += 1.0;\n"& " if (i>1000.0) break;\n"& "}\n"& "if (i>1000.0) i = 0.0;\n"& "gl_FragColor = vec4(i, i, i, i) / 75.0;\n"& "}" procedure init() theta = 0 -- Enable the required extension if gl_getVersion() >= 2.0 then -- Enable the features of OpenGL 2.0 (needed for the shader object functions). gl_enableExtension("GL_VERSION_2_0") else if message_box("Sorry, this program requires OpenGL version 2.0 or higher to run", "Error",MB_OK) then end if abort(0) end if program = gl_createProgram() fragmentShader = gl_createShader(GL_FRAGMENT_SHADER) -- Load and compile the shaders gl_shaderSource(fragmentShader, 1, fragmentShaderCode, NULL) gl_compileShader(fragmentShader) puts(1,gl_getShaderInfoLog(fragmentShader)&"\n") -- Attach the shaders to the program gl_attachShader(program, fragmentShader) -- Link and enable the program gl_linkProgram(program) gl_useProgram(program) lastTime = time() end procedure procedure animate() atom currTime gl_clearColor(0.4, 0.4, 0.5, 1.0) gl_clear(GL_COLOR_BUFFER_BIT) -- Enable the shaders gl_useProgram(program) gl_pushMatrix() gl_begin(GL_QUADS) gl_vertex2f({-1.0, -1.0}) gl_vertex2f({1.0, -1.0}) gl_vertex2f({1.0, 1.0}) gl_vertex2f({-1.0, 1.0}) gl_end() gl_popMatrix() gl_flush() -- Disable the shaders gl_useProgram(NULL) if ewSwapBuffers(glhDC) then end if currTime = time() theta += ((currTime-lastTime)/0.01667)*0.02 lastTime = currTime end procedure procedure key(integer keycode,integer x,integer y) if keycode = VK_ESCAPE then ewPostQuitMessage(0) end if end procedure procedure reshape(integer w,integer h) gl_viewport(0,0,w,h) end procedure procedure clean_up() gl_deleteShader(fragmentShader) gl_deleteProgram(program) end procedure -- Tell EuGL to use double-buffering euglInitDisplayMode(EUGL_DOUBLE) euglInitFunc(routine_id("init")) euglExitFunc(routine_id("clean_up")) euglDisplayFunc(routine_id("animate")) euglReshapeFunc(routine_id("reshape")) euglKeyboardFunc(routine_id("key")) EuGLMain(EUGL_HANDLE_EVENTS,"Mandelbrot shader",640,480)
14. Re: pointers to variables
- Posted by prickle Aug 03, 2009
- 1120 views
Hey, nice. Thanks for that one. Yes, GPU was a long term target for the JIT compiler but would require me lotsa booklearnin and a high end video card. It is, however, an ideal architecture for fractal computations at low precisions (shallow zooms). Correct me if I'm wrong, but AFAIK one only gets single precision floats in the current generation of GPUs.
Will the GL libs you are using work in Linux? They look nice.
Nick
15. Re: pointers to variables
- Posted by bernie Aug 03, 2009
- 1254 views
Very good. These base pointer offsets will end up hidden in my compiler's symbol table never to be seen again .
Now the questions - Does it support SSE4? what are the maximum number of args? are the base pointer offsets data dependent? are they always the same for the corresponding parameter? (I expect yes) The method you use for returning objects is not clear to me. Could you please elaborate?
Thanks Bernie.
Nick
Sorry, It does not support SSE4.
It is just meant to be used for general user programming.
( base pointer offsets data dependent? )
If you use "prolog4eu" then EBP + 8 will always point to the
LAST (right hand side) parameter in Euphoria parameter list
passed by Euphoria.
I really don't know what would be the limits of the number
of arguments. If you run into a limit you can always pass
a pointer to some allocated memory and take data from there.
Remember Euphoria uses the registers so the code has to return
the EAX 32-bit register which can be the data or a pointer to
the data.
If you really need a full blown compiler there is a wrapped
version of FASM assembler in the archive.
16. Re: pointers to variables
- Posted by mic_ Aug 03, 2009
- 1190 views
Will the GL libs you are using work in Linux? They look nice.
GL extensions (needed for things like fragment programs) are handled differently in Windows and Linux, so "no". My GLUT wrapper does work in Linux - at least the last time I tested it - but doesn't support GL extensions. I suppose that could be fixed, but since I use Windows 95% of the time I rarely write code for Linux.
17. Re: pointers to variables
- Posted by prickle Aug 03, 2009
- 1137 views
Thanks again Bernie. That's what I needed to know.
If you really need a full blown compiler there is a wrapped
version of FASM assembler in the archive.
I tripped over an improved version of Pete's mini-assembler in the archive that also supported all such ops. It really doesn't matter which assembler I use, as long as it has the features I need or I can add them as required. As I say, I won't need it for a while yet, I still need to reverse engineer my old code as I only vaguely remember how it works. There was some good reason I didn't finish it....
I do note there are expression parsers in the archive already but they appear to be interpreters not compilers and as such would run slower than Euphoria. My expression parser has an interpreter but it is only used to verify the correctness of compiled code in the test suite.
It suprises me that Euphoria still does not appear to have an "eval" method like Perl. It would make dynamic interpreted expression parsers absurdly trivial and have many other uses too. OK, throw that in the suggestions box.
Nick
18. Re: pointers to variables
- Posted by prickle Aug 03, 2009
- 1204 views
Will the GL libs you are using work in Linux? They look nice.
GL extensions (needed for things like fragment programs) are handled differently in Windows and Linux, so "no". My GLUT wrapper does work in Linux - at least the last time I tested it - but doesn't support GL extensions. I suppose that could be fixed, but since I use Windows 95% of the time I rarely write code for Linux.
That's a shame. I no longer use Windows at all. Still, GLUT is plenty good for now.
Thanks,
Nick
