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.
> Some AST terms might be synthesised and have no corresponding
> Sexpression.
Have an example? I didn't notice one with this property.
>> 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.
>> There are a couple high level concepts that we could break out into
>> their own separate libraries:
>>
>> 1. reading and typechecking the flx files
>> 2. reading (and not typechecking) the AST s-expressions
>> 3. writing out the AST in felix
>> 4. writing out the AST in s-expressions
>> 5. converting the AST to c++
>> 6. converting the AST to llvm
>> 7. shared data structures
>
> You can do this, but it is pointless and will damage performance.
> Marshaled data is typically unreadable except by the program that
> wrote it.
> Data written in specified format is portable but much more expensive
> to
> read and write.
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.
> In both cases there is wasted I/O and conversion which will hurt
> performance,
> AND extra complexity maintaining the I/O code.
It doesn't have to be. That was what I was trying to say with the flxc
stuff. Just because we would support writing out the AST in some form
doesn't mean that we'd have to make the compiler follow that path.
flxc could just on it's merry way using the library to route things
around inside ocaml. It's the other drivers that would help me.
> Actually the raw AST_* expressions are not very important, they're
> fairly
> arbitrary rubbish representing the input syntax.
>
> The more important terms are the SYMTAB EXE_ etc terms (for the
> front end)
> and the BEXPR and BEXE terms for the optimiser and back end.
>
> BEXE/EXPR are a minimal "machine code" or "calculus" produced after
> lookup replaces text names with integer symbol table indices
> (effectively
> this is alpha-conversion).
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?
>> 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? I suppose that would be okay.
What would you do with:
match "foo" with
| "foo" => ...
| "bar" => ...
| "baz" => ...
...
endmatch
Create a Convert those into if-then-elses?
>> 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. Anyway,
I'm new to them, so I don't know if this is an llvm thing or not. So
each block of code in between a branch they call a basic block. So:
fun f () {
// first basic block
var a = 1;
var b = a + 3;
var c = g b;
var d = 0;
if b < c do
// second basic block
d = 1;
else
// third basic block
d = 2;
done;
// fourth basic block
return d;
}
So, one of the requirements with llvm code is that all basic blocks
must end with a terminator. Those are branches, returns, and etc. So,
in order to be valid code, that function needs to be turned into this:
define i32 @f() {
; the first basic block
entry:
%a = 1
%b = add i32 %a, 3
%c = call i32 @g(i32 %b)
%d = 0
%test = cmp slt i32 %b, %c
%br %test, label then, label else
; the second basic block
then:
%d.1 = 1
br label endif
; the third basic block
else:
%d.2 = 2
br label endif
; the fourth basic block
endif:
%d.3 = phi i32 [ %d.1, %then ], [ %d.2, %else ]
ret i32 %d.3
}
>> I'm ignoring support for arbitrary gotos at the moment. Will bad
>> things happen if I do this? Are there other things that should be
>> pushed to the backend?
>
> Felix uses goto because it is most general, it subsumes blocks.
> However, when blocks exist,
> an analysis routine would have to construct it.
>
> The optimiser should really do this -- convert the program into
> blocks, which is needed
> for many analyses, eg control/data flow.
Of course. I'll see if the llvm folks know of a nice way to extract
blocks from goto-soup.
>> Fifth, where'd you all go? I hope we can get some more involvement
>> to help me with all this :)
>
> I'm still working on my boat.. I'm here .. though I just got a $2500
> bill from Telstra
> for my wireless internet which is ABSURD. I may have to chuck that
> most useless
> and stupid of suppliers .. I can't believe how totally and utterly
> incompetent they are.
That is insane. I've heard they're bad, but I never heard of a bill
that bad.
-------------------------------------------------------------------------
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
