On 23/05/2008, at 7:59 AM, Erick Tryzelaar wrote:
> On May 22, 2008, at 3:12 AM, john skaller wrote:
>
>>
>> On 22/05/2008, at 5:42 PM, Erick Tryzelaar wrote:
>>
>>> What I really want is to really just see the AST in some s-
>>> expressions. So why don't we add two ways of displaying the AST?
>>> And if the AST s-expressions can completely represent the AST, we
>>> could read it back in.
>>
>> There are already routines to print both Felix Sexpressions and the
>> raw AST.
>
>
> Are there? I only saw the Flx_print, which just outputs the almost-
> felix code.
Sure, there's a sexprint somewhere, there has to be or I'd never be able
to debug it. The AST print code does output "almost felix" code, so
isn't
entirely reliable for deducing the AST_ terms.. annoyed me quite often.
It also can't be compiled, so it is a bit of a non-functional
messiness ..
>
>
>> Some AST terms might be synthesised and have no corresponding
>> Sexpression.
>
>
> Have an example? I didn't notice one with this property.
>
Sure, look in the desugaring code, where routines are used to convert
AST_curry function nests into discrete functions, or similar code
which unravels chains of * and + operators into either a type product
or a nest of multiply or add function applications. You will probably
also find
some AST terms which cannot be generated by the parser, but are used
in the macro and desugaring reductions.
>>> Second, the compiler is very monolithic, but it doesn't have to be.
>>
>> No, not really. It runs multiple independent passes, typically
>> linked only by single "term"
>> sent from one to the other plus some global cache (unfortunate).
>
>
> What I meant is that there aren't clear subsets that src/compiler/
> frontend (and the iscr packages before) is really a bunch of files
> that don't necessarily all directly depend on each other. Can we group
> all the files that relate to certain subsets of the code into their
> own directories? It would at least help me see how things flow from
> one place to another.
Sure, you can try. However these libraries will be sequentially
dependent, both on each other and internally, so you won't really
gain any separation. The existing file structure is a property of using
interscript, and because multiple directories make scripted tools much
harder to write.
The latter is partly a design problem in Ocaml: you cannot write like
in Python
open Dir.Mod
Dependencies are therefore going to be like
../sibling
which is bad style: you should never depend on a sibling
directory. In particular in Ocaml the only way to do that would require
adding more and more components to search paths: maybe OK for
Ocaml itself but ocamldoc, ocamldep etc are likely to be confused
by this.
>
> The idea with marshaling the data is that we'd have a library for
> reading and writing it that the felix compiler and other utilities
> would use. That ought to make it portable on the same system.
Yes, though it doesn't help with 3PL code written in, say, C.
>
> Oh, by AST, I'm not just talking about AST_*, I meant the EXE/BEXE/
> EXPR stuff as well. Is there a different term you use to refer to all
> of these tree structures?
yes, the term is "term" :)
>
>>> Third, I'd like to at least push converting matches into gotos into
>>> the backend.
>>
>> I think what is more appropriate is converting matches to switches
>> in the front
>> end and switches to goto in the back end.
>
>
> Are you talking about c-style switches?
Yes, more or less. At the moment a goto-chain is synthesised in the
front end. This is bad, because it prevents later type analysis, for
example
checking case completeness.
It's also the case the some match types such as integer switches are
logically
quite distinct from say float range matches.. but all these cases are
treated
exactly the same in the very front end, making a goto chain, and thus
defeating
optimisation and diagnostic analysis.
Felix generates:
if(not match-check()) goto next-case
call match handler()
goto finish
next-case: ...
which also "double handles" the test argument.
>
>
>>> Llvm needs to but at the end of every basic block, but the felix
>>> frontend assumes that gotos can fall through.
>>
>> Huh?
>
>
> Are you familiar with basic blocks? I think they're from SSA.
Even more basic, I think Wirth might have invented them.
But it just a sequence of instructions with a single entry and single
exit, possibly the exit is a conditional goto (so at the end logically
there are one of two "branches" out, one is usually defaulted
to dropping through, in a proper analysis the drop through is
replaced by an explicit goto).
>
> So, one of the requirements with llvm code is that all basic blocks
> must end with a terminator.
Usually it is the other way: you take some (low level) code and
try to find the basic blocks, by looking for labels and gotos.
>
> Of course. I'll see if the llvm folks know of a nice way to extract
> blocks from goto-soup.
>
There is no need, it is trivial. a block is something starting from
a label, and proceeding up to the next label or branch.. that's it.
Felix already scans for these things in the optimiser.
For example this is used to propagate "val" values.
[Note: "val" values in Felix are not immutable, even though the
end user can't directly change them, for example:
loop:
val x = f y;
++y;
goto loop;
This is a pain..
>
--
john skaller
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
