skaller wrote:
>> 1) Shootout entry. (http://shootout.alioth.debian.org/)
>> > It's not just about speed, it's a tool to compare language style and 
>> > syntax. All "big/active player" languages are present there, and the 
>> > language which isn't looks as a project which have no enough resources 
>> > to survive. When choosing a new language, i've found myself constantly 
>> > returning to Shootout.
> 
> Felix was in the shootout but got kicked out by Isaac Gouy.

Ahh. I see.
http://lists.motion-twin.com/pipermail/neko/2006-May/000931.html
Perhaps it is possible to include some more of (possibly old) Shootout 
tests in http://felix.sourceforge.net/speed/en_flx_perf_top.html ? And 
improve the output a bit - explain which is which in
"Rankings for ack on rosella
     felix            13   5.51 [N=  3 SD= 2%]
     gnat             13   9.59 [N=  1 SD= 0%]
     gccopt           13   9.84 [N=  2 SD= 0%]"

>> > I think it is very important to provide a way of running Felix under a
>> > managed runtime. Modern language user expect stack traces and safety 
>> > from it's language!.. C++ audience is diminishing, not growing, because
>> > pure C++ lacks that safety. Felix should took pains, *if it is 
>> > possible*, to provide easy, either out-of-the-box, or supported 
>> > (automatically tested) and docummented compilation of Felix into .NET 
>> > managed DLL's (Visual C++ targeting CLR) and maybe LLVM bytecode. 
> 
> I agree, .NET support would be good .. of course I have it on XP32
> and XP64 (not Vista yet) but I don't really have the expertise
> to develop a .NET instantiation -- I guess you'd throw out the
> Felix gc and use the .NET one.

You don't need to change the GC in order to run under the managed C++.

I think this is largely independent things. You can
a) have an external garbage collector (like 
http://smieciuch.sourceforge.net/) in C++, but you already have one, and 
independently you can
b) compile C++ into CLI and allocate value types on the unmanaged heap, 
as in the usual C++.
http://msdn2.microsoft.com/en-us/library/ms384241(VS.71).aspx

> At present, Felix doesn't touch the machine stack. The Felix gc
> can't run whilst it is non-empty. Procedures use their own
> heap based 'spaghetti stack' to solve this.
> 
> At present (noninlined) Felix functions use the machine stack,
> so they can be called inside C expressions. For example:
> 
>       fun add: int * int -> int = "$1+$2";
>       fun square(x:int)=> x * x;
>       ....
>       val x = square a + square b;
> 
> The transparency extends with difficulty to callback functions
> provided the callback provides a 'client data' pointer.
> 
> Procedures in general can't work in callbacks .. that is,
> plain procedures are fine, but felix threads can't operate
> because the stack isn't empty, and context switching relies
> on cooperative yielding to the Felix scheduler.
> 
> There's no portable way around this: Felix can use gcc specific
> hackery if it is an optimsation and can be wrapped in macros
> so the generated code remains 100% portable (and it does,
> it uses assembler labels and computed gotos).
> 
> To unwind the machine stack .. I just throw a C++ exception,
> but of course you can't recover from that.

Whether the stack is implemented in a separate stack memory or in the 
heap is an implementation detail. The question is - can it be unwound it 
to provide a stack trace?


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to