Re: An illuminating experiment using platform().
- Posted by CChris Jul 13, 2008
- 816 views
deferred_ifdef would parse all the alternatives, and make notes about where each starts and ends. When InputIL() is invoked on the target platform, it will cut the unnecessary IL off, so that the backend will execute _as if_ the ifdefs had been resolved on the same machine.
One file to distribute, no parse time. The added decoompression overhead is negligible, unless there are a ton of ifdefs.
If you want more speed, then have straight exevcutables by cross translation. The deferred_ifdef route would be a very convenient intermediate step between plain source and plain .exe .
CChris
If I understand correctly then, its basically an ifdef that is outputed into the IL and then interpretered by the backend at run time....
It is possible to take IL and reverse engineer it into almost the original euphoria source code quite easily. I think there is a tool provided to do this. We no longer seem to have shrouding as in the old days where the source was completely hidden (or scrambling?). I therefore do not think having a deferred_ifdef solely for the benefit of shrouded code makes sense. If it benefits translated or interpreted code as well, then it could still be worthwhile.
For interpreted code, we don't need the ifdef to be deferred, since from the user's point of view parse time is the same as run time. So no benefit here.
For translated code, the deferred_ifdef would need to be parsed and evaluated before the conversion to C code anyways. (Even if it wasn't, the result C code is only expected to work on a single platform, so there is no benefit to preventing optimization.) If we care, a similar argument applies to the case of bound executables.
So it looks like a deferred_ifdef only helps the shrouded code case be more portable. The use of raw IL files seems to be rare.
If we had a way to cross-compile IL files, and perhaps do cross-binding, I'd say there was no need for an deferred_ifdef even for shrouded code.
You got it right. The use of raw IL files is rare because of:
- it wasn't possible at all before 3.0, which isn't too old;
- the platform issues were, and are, there.
Cross-output of IL, ie telling Eu that OSX is defined and WIN32 isn't ven though IL is output under Windows, would take care of the issue. And make use of raw IL more frequent, as it solves any parse time issues.
CChris
