On 06/02/2014, at 9:32 AM, srean wrote:
> Another option which is closer to Raoul's suggestion is to have a flag to
> disable inlining globally for debugging purposes.
--inline=10
--debug
--debug-compiler
--usage=prototype
--usage=debugging
--noinline
Note: at present turning inlining off completely isn't possible. The
optimisation
pass does some essential work which cannot be removed from the process.
So --noinline crashes the compiler at the moment. The smallest value of
--inline is 10. This says don't inline functions over 10 "instructions",
unless explicitly marked inline. Most recursive functions can't be inlined.
In your code "inline" and "noinline" should be respected. This is a relatively
new feature.
One must get used to the fact that in Felix. "inline" is not merely an
optimisation.
It has semantics. I'm not saying exactly what they are, but you can get away
with
some nasty crap if you force inline a function. For example, although functions
cannot do schannel I/O .. if you do schannel I/O in an inline function and
call it directly in a procedure .. it will work. Futures are implemented using
this hackery.
I know this sounds bad but it isn't. An inline function is just a procedural
form which happens to look like a function. That is, it returns a value
instead of using a procedure to store a value "at a pointer". In particular
this is easier to deal with because pointers require alias analysis etc.
Just don't expect an inline function used as a closure to obey the
same rules, clearly such usage tends to preclude inlining.
Another thing Felix *forcibly* does is eliminate all functions by converting
them to procedures. So you can tend to get away with things you're
NOT supposed to do in functions because Felix converts them to procedures.
Again, this can't be done for functions converted to closures. The reason is
the C++ ABI. Felix functions HAVE to use the machine stack for return addresses
as closures or C++ expressions wouldn't work.
So is all this behind the scenes hackery without really solid semantic
assurances
good?
Of course not. I just don't know, at present, how to solve this problem.
[problems.. plural .. actually]
Apart from dumping the C++ ABI, which is tempting. Of course that
has consequences in terms of not being able to leverage existing
C++ code AND having to write back ends that generate assembler.
Ocaml tool that approach. It certainly has merit. But it makes the
product difficult to maintain and optimise as new CPU designs
come out.
So one need to have some confidence these issues are not as bad
as it may appear. They're just not. I have written a lot of Felix code
now and these issues don't arise that often. As an experimental
language I NEED people to experiment to gather enough data
to design a better solution.
Lets put it this way: given a choice between writing C, C++, Python
or Ocaml (the languages I know best), I will choose Felix. Ocaml is better
at the moment for compiler writing, and for Felix the fact I have a ready
made parser (Dypgen) and Scheme interpreter (OCS) is hard to beat.
And of course Ocaml compiles miles faster than Felix. But Felix is just
easier to use.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
