OpenEuphoria

2. Re: Precompiled include files

• Posted by mattlewis (admin) Jul 11, 2013
• 1596 views

Yes, I've thought about this some. See RoadmapBeyond:

Matt

4. Re: Precompiled include files

• Posted by mattlewis (admin) Jul 11, 2013
• 1572 views

It depends on the implementation, but probably not. My idea makes it all work seamlessly from the user's perspective, which means that it's integrated with how the symbol table is built and how code is parsed.

Matt

6. Re: Precompiled include files

• Posted by jimcbrown (admin) Jul 11, 2013
• 1609 views

No. The shrouded and scrambled code was just a form of obsfucation. The interpreter (rather, the parser) would essentially unobsfucate it back into something like its original form before executing it. Rather than being more efficient like precompiled code, it instead added a step to the execution process.

Shrouded code uses the same bytes that are used in other file encodings that go beyond ASCII (e.g. UTF-8). Getting the old shrouded code to work now that we're moving to support Unicode is not a trivial task.

8. Re: Precompiled include files

• Posted by jaygade Jul 11, 2013
• 1590 views

My main point was more for translating than for other uses. Files like std/convert.e could be compiled into convert.o and then linked to the rest of the .o files when doing a translate.

Currently when doing "make" on the source, the std/include files get compiled, linked, and then discarded several times in the process.

10. Re: Precompiled include files

• Posted by mattlewis (admin) Jul 11, 2013
• 1543 views

Not very. The .il files are dumps of the symbol tree (which includes all of the code). So all of the references in the .il file only work for that particular file. You can't combine them.

There has been talk in the past about coming up with a more flexible way that would be similar to compiling a file to IL, then linking various IL files together. I think that would take quite a bit of work, and I'm not sure how much of a benefit it would be.

Matt

12. Re: Precompiled include files

• Posted by jaygade Aug 11, 2013
• 1435 views

I'm not talking about .il files OR .dll (or .so or .dylib) files. I'm talking about translating and compiling std/*.e files to .c and .o files during a project build.

I'm mainly talking about building Euphoria, although the same could apply to other larger projects. The same std/*.e file gets translated into a .c file and then compiled into a .o file and then finally linked in to the project. This seems wasteful when it happens several times during a build, when these files change extremely rarely.

14. Re: Precompiled include files

• Posted by jaygade Aug 12, 2013
• 1399 views

I don't know anything about inlining.

It does seem to me, though, that the Translator can be at least as smart as Make when it comes to which files have been modified.

It may not be a simple change, but it should be a doable change.

Scenario:

1. Make is building the interpreter.
2. One of the interpreter files includes std/convert.e.
3. The translator accepts a command flag that says "reuse compiled library files".
4. But that the library file hasn't been translated yet, or the .e file is newer than the .c or .o file.
5. The translator translates and compiles the file, and saves it to a known location. It does this for all std/*.e files included in the project. (I don't whether it's worthwhile for project-specific or all .e files in a project?)
6. The translator finishes its build of the interpreter and deletes all of its old files EXCEPT the compiled library files.
7. Make is building the translator.
8. One of the translator files includes std/convert.e
9. The translator accepts a command flag that says "reuse compiled library files".
10. The translator finds the precompiled .c or .o file and compares it to the .e file, and sees that it's newer.
11. The translator uses the precompiled file in its build of the translator, saving cycles and time.
12. The translator finishes its build of the interpreter and deletes all of its old files EXCEPT the compiled library files.

And finally, the developer makes some changes to some project file or other and does another build; but he saves a lot cycles and time because a third or so of the project is already built. If there's a conflict, there can be a 'make clean' target which removes the precompiled files from the build directory.

Again, this is just brainstorming. If this ONLY affects building of Euphoria and not other projects then it might not be worth doing.

16. Re: Precompiled include files

• Posted by jaygade Aug 12, 2013
• 1428 views

That's interesting, and it doesn't seem to match my recent experiment. I created these two files and ran "euc -nobuild" on them to examine the .c files.

-- convert1.ex 
include std/console.e 
include std/convert.e 
 
object cmd 
 
cmd = command_line() 
 
if length(cmd) < 3 then 
	display("[] requires at least 1 argument", {cmd[2]}) 
	abort(1) 
end if 
 
display(to_string(cmd[3])) 

-- convert2.ex 
include std/console.e 
include std/convert.e 
 
object cmd 
 
cmd = command_line() 
 
if length(cmd) < 3 then 
	display("[] requires at least 1 argument", {cmd[2]}) 
	abort(1) 
end if 
 
display(to_number(cmd[3])) 

convert.c was identical in both cases, and seemed to contain all of the exported functions of convert.e, as were all of the .c files created from other std/*.e files. I don't see any stripping or optimization being performed on these files.

I may be misunderstanding, but doesn't the translator treat files on its command line differently from files "included" within another file? I'm only guessing that from experiments not from actually studying the code.

Admittedly I'm testing with 4.05 on Windows right now. Maybe my example is too small or it's different on 4.1.0 -- I'll have to test it later.

Edit: Nevermind. I just did another experiment and I see that it creates a much different file.

18. Re: Precompiled include files

• Posted by mattlewis (admin) Aug 12, 2013
• 1376 views

It looks like 4.1 is better at removing things. I think this is probably due to better routine_id analysis. When I tried your examples using a 4.1 translator, I checked for the respective to_string/to_number that wasn't used, and they weren't there where you'd expect them to not be there.

Matt

20. Re: Precompiled include files

• Posted by SDPringle Aug 13, 2013
• 1360 views

Yes, the version of the translator the defined words and the defined words will effect the resulting C code. Even if you compare the convert.c in intobj and transobj using the same interpreter/translator you will find different symbols inside the routines and different names for the routines themselves. They must be named this way to avoid conflicts among routines that have the same name.

These routines are not even necessarily functionally equivalent if I understand what Matt is saying.