Front page | perl.perl6.internals |
Postings from October 2005
Re: Tcl - compiling
Thread Previous
|
Thread Next
From:
Will Coleda
Date:
October 3, 2005 13:57
Subject:
Re: Tcl - compiling
Message ID:
3CD436E4-DE99-4483-A64B-F5B3BB37EB83@coleda.com
Committed: partcl is now now a compiler. Though some tests still fail
(leo fixed one of the unicode issues)
t/cmd_global.t 3 768 6 3 50.00% 2-4
t/cmd_proc.t 4 1024 11 4 36.36% 3-4 8-9
t/cmd_return.t 1 256 2 1 50.00% 1
t/cmd_string.t 2 512 57 2 3.51% 45-46
t/tcl_backslash.t 4 1024 35 4 11.43% 31-34
Jerry Gay was getting bored with all tests passing, so this is for
him. =-)
Thanks to a conversation on #parrot with leo, I have a lead on fixing
the problems with global, proc, and return: but I think the easiest
solution will involve completing one of the upcoming items below, so
committing as is for now. The unicode issues in the last two test
files above could use some time to track down. Ping me if you'd like
work on this.
Next few compiler related things to do:
1) provide inline-able versions of builtins. (on the short list:
anything in examples/bench.tcl)
2) Change the compiler to call those if they're available. (For
anything that has an inlinable version, we can replace the
interpreted version with a call to the compiled version.)... this
will temporarily brake some rename tests, but:
3) Keep a global counter that is incremented whenever a procedure is
created or rename'd. When generating the compiled code, key against
this counter - if it's changed, we must fall back to the interpreted
version. (which, although it starts out with a a call to the compiled
builtin, might have been replaced at that point.).
4) Provide a way to dump the total generated PIR code instead of
compiling & executing it.
Regards.
On Oct 2, 2005, at 1:40 AM, Will Coleda wrote:
> The simple version of the compiler is now mostly done in my sandbox:
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ----------------------------------------------------------------------
> ---------
> t/cmd_global.t 3 768 6 3 50.00% 2-4
> t/cmd_proc.t 4 1024 11 4 36.36% 3-4 8-9
> t/cmd_return.t 1 256 2 1 50.00% 1
> t/cmd_string.t 3 768 57 3 5.26% 21 45-46
> t/tcl_backslash.t 4 1024 35 4 11.43% 31-34
>
> These break down into two classes of errors:
>
> 1) ``Pad index out of range'' {global, proc, return}
>
> 2) Data::Escape::String can't escape unicode {string, backslash}
>
> I've opened a TODO ticket for #2: [perl #37321] Any takers on this
> appreciated.
>
> If I can get #1 working, I'll just TODO everything that depends on
> #2 and get this checked in.
>
> I've attached the generated PIR output for the sample program,
> which outputs "10"
>
> set a 0
> while {$a < 10} {
> incr a
> }
> puts $a
>
> It's functional but ugly. (Patches welcome once I checkin)
>
>
> <output.txt>
>
> On Sep 30, 2005, at 1:39 PM, Amos Robinson wrote:
>
>
>> Eeek. Yes, I forgot just how crazy a language it was. :-D
>>
>>
>>
>>> Yes, that's the plan, but the initial implementation isn't going to
>>> be a compiler like most people would expect:
>>>
>>> For example, something like:
>>>
>>> while {$a < 10} { incr a }
>>>
>>> while isn't language syntax. it's a command. So, this code would
>>> result in creating two PMCs for the args (first arg is {$a <10},
>>> second is {incr a}), and then lookup the while PIR .sub, and invoke
>>> it with the two PMC args.
>>>
>>> Future versions of the compiler will be able to cheat (presuming the
>>> while builtin hasn't been overriden) and generate inline-able PIR,
>>> which should improve performance.)
>>>
>>> Regards.
>>>
>>>
>>>
>>
>>
>>
>>
>
>
Thread Previous
|
Thread Next