1. Dynamic calling
- Posted by useless Sep 19, 2009
- 1293 views
Re:
http://openeuphoria.org/docs/eu400_0095.html
It's not clear to me what can be put into allocated memory marked as executeable.
If i have a running application that allocated the memory, tagged it as executeable, do i load a Eu source code file into it? Or a pre-interpreted IL file (and how do i get that IL?)? Or does it need to be a dll? If i can load some Eu source code into it and then routine_id to it, isn't that string execution?
If i do this, say, 2000 times, is memory going to be so fragmented that winxp is nuked?
useless
2. Re: Dynamic calling
- Posted by jimcbrown (admin) Sep 19, 2009
- 1282 views
Re:
http://openeuphoria.org/docs/eu400_0095.html
It's not clear to me what can be put into allocated memory marked as executeable.
Anything can be put in there. But the intention is to put machine code in that location and have the cpu execute it. (If DEP is on, and the allocated memory is not marked as executable, and you try to run the machine code in there, the program will be terminated with a GPE violation or similiar error.)
If i do this, say, 2000 times, is memory going to be so fragmented that winxp is nuked?
Marking it as executable doesn't make memory any more or less fragmented. So the answer is the same as it was for 3.1.1
3. Re: Dynamic calling
- Posted by useless Sep 19, 2009
- 1288 views
Re:
http://openeuphoria.org/docs/eu400_0095.html
It's not clear to me what can be put into allocated memory marked as executeable.
Anything can be put in there. But the intention is to put machine code in that location and have the cpu execute it. (If DEP is on, and the allocated memory is not marked as executable, and you try to run the machine code in there, the program will be terminated with a GPE violation or similiar error.)
[/quote]
Ok, my intention would be to put Eu source code there. Must i
1) figure out how to put IL code there for the backend to execute (i run everything in either euiw.exe or eui.exe for this)?
2) i bind-make-compile-whatever all the millions (yes, literally) of things i want to execute, to x86 code? So i pretty much can't modify it while it's in memory, as far as adding more, or changing, the Eu code that it came from? Unless i can pull off recompiling the new code and loading it on top of the existing routine_id?
If i do this, say, 2000 times, is memory going to be so fragmented that winxp is nuked?
Marking it as executable doesn't make memory any more or less fragmented. So the answer is the same as it was for 3.1.1
Which was? It's still making a lot of allocations, and by your statement, the routine_id will fall in the 2gig space windose allows for each application+data(?), so the allocation won't be paged out(?) and the routine_id will always be good.
EuKat err, useless
4. Re: Dynamic calling
- Posted by jimcbrown (admin) Sep 19, 2009
- 1269 views
Ok, my intention would be to put Eu source code there. Must i
1) figure out how to put IL code there for the backend to execute (i run everything in either euiw.exe or eui.exe for this)?
2) i bind-make-compile-whatever all the millions (yes, literally) of things i want to execute, to x86 code? So i pretty much can't modify it while it's in memory, as far as adding more, or changing, the Eu code that it came from? Unless i can pull off recompiling the new code and loading it on top of the existing routine_id?
Just do what you did for 3.1.1, changing allocate() to allocate_code(), and it should still work.
Marking it as executable doesn't make memory any more or less fragmented. So the answer is the same as it was for 3.1.1
Which was?
That is a good question. I don't know the answer to this.
It's still making a lot of allocations, and by your statement, the routine_id will fall in the 2gig space windose allows for each application+data(?), so the allocation won't be paged out(?) and the routine_id will always be good.
Marking memory as executable doesn't affect paging AFAIK.
5. Re: Dynamic calling
- Posted by useless Sep 19, 2009
- 1226 views
Ok, my intention would be to put Eu source code there. Must i
1) figure out how to put IL code there for the backend to execute (i run everything in either euiw.exe or eui.exe for this)?
2) i bind-make-compile-whatever all the millions (yes, literally) of things i want to execute, to x86 code? So i pretty much can't modify it while it's in memory, as far as adding more, or changing, the Eu code that it came from? Unless i can pull off recompiling the new code and loading it on top of the existing routine_id?
Just do what you did for 3.1.1, changing allocate() to allocate_code(), and it should still work.
[/quote]
<sigh> PLEASE TELL ME WHAT TO DO.
useless
6. Re: Dynamic calling
- Posted by jimcbrown (admin) Sep 19, 2009
- 1205 views
<sigh> PLEASE TELL ME WHAT TO DO.
useless
Aside from changing allocate() to allocate_code() and a set of 4.0isms (i.e. include files in std, and new keywords like label, loop, etc), nothing has changed.
Just keep doing what you did to make this work in Euphoria version 3.1.1, and it should still work. (On the other hand, if this never worked in 3.1.1, DEP won't help you one iota in making this work in 4.0)
7. Re: Dynamic calling
- Posted by DerekParnell (admin) Sep 19, 2009
- 1206 views
Re:
http://openeuphoria.org/docs/eu400_0095.html
It's not clear to me what can be put into allocated memory marked as executeable.
Anything can be put into executable RAM, however it is normally only used for holding machine code.
If i have a running application that allocated the memory, tagged it as executeable, do i load a Eu source code file into it? Or a pre-interpreted IL file (and how do i get that IL?)?
Neither. Both source code and IL are data and not machine code. You do not need to use executable RAM for either of these things.
Or does it need to be a dll?
Or does what need to be a DLL? I'm not sure what you are referring to by "it" here.
If i can load some Eu source code into it and then routine_id to it, isn't that string execution?
No, it is not string execution. String execution is where you get your application to invoke the Euphoria interpreter to 'execute' a string containing Euphoria source code. Loading source code into a RAM location and calling routine_id() won't work. The routine_id() function needs a string containing the name of a parsed function to call as an argument and all you would have is a RAM address and a string containing source code - and neither of those is the name of a routine that has already been parsed.
In order to use executable RAM in this manner, you would have to somehow convert the Euphoria source code to real machine code, and load that machine code into executable RAM and then invoke it using the c_func() routine.
If i do this, say, 2000 times, is memory going to be so fragmented that winxp is nuked?
Loading 2000 times or allocating 2000 times? But in any case, that wouldn't trouble XP at all.
8. Re: Dynamic calling
- Posted by useless Sep 19, 2009
- 1278 views
<sigh> PLEASE TELL ME WHAT TO DO.
useless
Aside from changing allocate() to allocate_code() and a set of 4.0isms (i.e. include files in std, and new keywords like label, loop, etc), nothing has changed.
Just keep doing what you did to make this work in Euphoria version 3.1.1, and it should still work. (On the other hand, if this never worked in 3.1.1, DEP won't help you one iota in making this work in 4.0)
So i can keep on not ever using routine_id with allocated memory, and it will now magically work? How does that work?!
I realise now that english is terribly ambiguous language, where no one knows what i am saying. I do not know how to say that i don't know what to do. All i know up till this point in this thread is to keep not executing code in allocated memory, and it will now work properly. As i said, i don't know what to put in that memory, and i said i would rather think IL code from the front end would be fine, since the euiw.exe backend is doing the executing. But you haven't given me a yea or nay on this, nor how to get the shiney new IL code to put there (i want to load it from a harddrive or another memory location). I don't understand why it would be x86 machine code, because i have used routine_id in Eu source code to refer to procedures written in Eu, and if i understand the frontend-backend thing correctly, there's no machine code between them. Can anyone answer this and give be directions, or explain this to Jim?
useless
9. Re: Dynamic calling
- Posted by jimcbrown (admin) Sep 19, 2009
- 1273 views
So i can keep on not ever using routine_id with allocated memory, and it will now magically work? How does that work?!
I have already answered this:
(On the other hand, if this never worked in 3.1.1, DEP won't help you one iota in making this work in 4.0)
I realise now that english is terribly ambiguous language, where no one knows what i am saying. I do not know how to say that i don't know what to do. All i know up till this point in this thread is to keep not executing code in allocated memory, and it will now work properly. As i said, i don't know what to put in that memory, and i said i would rather think IL code from the front end would be fine, since the euiw.exe backend is doing the executing. But you haven't given me a yea or nay on this, nor how to get the shiney new IL code to put there (i want to load it from a harddrive or another memory location). I don't understand why it would be x86 machine code, because i have used routine_id in Eu source code to refer to procedures written in Eu, and if i understand the frontend-backend thing correctly, there's no machine code between them. Can anyone answer this and give be directions, or explain this to Jim?
DEP won't help and is not needed, is in fact completely useless, for this purpose. You need an eval() for Euphoria.
10. Re: Dynamic calling
- Posted by useless Sep 19, 2009
- 1300 views
So i can keep on not ever using routine_id with allocated memory, and it will now magically work? How does that work?!
I have already answered this:
(On the other hand, if this never worked in 3.1.1, DEP won't help you one iota in making this work in 4.0)
And i said i never DID that, so i don't know if it would have ever WORKED, and i don't know HOW to do it in v3.1.1 or v4, so i asked for DIRECTIONS. So when you say to keep doing that like i did, "like i did" = "not doing it at all", which makes "it works like it always did" be illogical. I stored the occasional DATA in memory, but never ever tried to execute the data there, because it wasn't machine code.
Ok, talked to Derek on irc, it was enlightening, and sad. No way at all to make eu code into something that the interpreter will be happy executing in a routine_id call to allocate() or allocate_code(). Unless, and this is just me thinking, er, on the keybd, of a stub of machine code at the routine_id, instead of the actual code i wish to run. The stub makes the routine_id look normal, and handles the code of a bound eu code i want to run in a hidden manner. I know it won't work, Derek told me already. But i did think of it.
useless
11. Re: Dynamic calling
- Posted by mattlewis (admin) Sep 19, 2009
- 1304 views
- Last edited Sep 20, 2009
Ok, talked to Derek on irc, it was enlightening, and sad. No way at all to make eu code into something that the interpreter will be happy executing in a routine_id call to allocate() or allocate_code().
The ability to dynamically parse and execute code in a running program (similar to perl or javascript eval) may be implemented in a future version of euphoria. There is no (convenient) way to do this currently. I suppose that the closest you could get would be to write the code out to a file, use the translator to build a dll/so/dylib, and then use the compiled result through the open_dll/define_c interface.
Matt
