Re: IL Engineering Library
- Posted by jimcbrown (admin) Mar 05, 2015
- 4407 views
Given:
string = "atom a\na+=1\n? a" -- 15 bytes existing code1 convert_and_inject(string) existing code2and then i do
string = getf("c:\\euphoria\\200bytes_of_code.eux") -- 200 bytes
existing code1
convert_and_inject(string)
existing code2
and then i do do it again
string = "atom a\na+=1\n? a" -- 15 bytes existing code1 convert_and_inject(string) existing code2and you are saying the string lengths do not matter
Yes, i know that the IL code isn't the same size as the source code, but i needed some numbers to toss around.
That's correct. String lengths do not matter, IL code lengths do. Lets assume then that the IL bytecode length is the same as the source code lengths. (This is obviously not true, the IL will be a lot shorter, but calculating the true lengths without a bytecode compiler would be a headache - at least for me.)
The first run thru the code, the conversion and injection of 15 bytes of source is straight forward. But the 2nd time, the previous injected IL is wrong, string is now whatever was in that file, so the effects of the first injection need undoing, or overwriting.
Naturally. The programmer has control here and has the ability to choose to overwrite, instead of inserting, IL code. The programmer will also have the ability to delete segments of IL to undo an injection operation.
Either a large block, with potentially a lot of NOPs must be allocated between existing code1 and existing code2, or it must be dynamically relocated each time string is IL'd and injected.
Currently, the former is true for the C-based bytecode interpreter. The Eu-based bytecode interpreter (eu.ex) stores the IL in a sequence.
