STG to JavaScript translation
Hello. I'm working on the translation of GHC's STG language to JavaScript. I've started my implementation, but I've got stuck with the STG case statements. The problem is the binder in case expression. StgCase expr livevars liverhsvars bndr srt alttype alts Operationally, I need to save continuation and evaluate expr expression, but I have no idea what to do with the bndr. It seems to me that I need to build a closure binded by bndr with the body of expr evaluate it, update it, and use it in RHSs of alternatives. But It seems that this behavior isn't intended by GHC. Can you explain briefly how GHC implements this binder and what this binder points to. Here are some notes about Dmitries last year activity and my activity: http://haskell.org/haskellwiki/STG_in_Javascript -- vir http://vir.comtv.ru/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: STG to JavaScript translation
Hi Are you aware that Dimitry is still working on ycr2js - and has made great progress. There are details available in The Monad Reader, issue 7 (http://www.haskell.org/haskellwiki/The_Monad.Reader) Thanks Neil On 9/17/07, Victor Nazarov [EMAIL PROTECTED] wrote: Hello. I'm working on the translation of GHC's STG language to JavaScript. I've started my implementation, but I've got stuck with the STG case statements. The problem is the binder in case expression. StgCase expr livevars liverhsvars bndr srt alttype alts Operationally, I need to save continuation and evaluate expr expression, but I have no idea what to do with the bndr. It seems to me that I need to build a closure binded by bndr with the body of expr evaluate it, update it, and use it in RHSs of alternatives. But It seems that this behavior isn't intended by GHC. Can you explain briefly how GHC implements this binder and what this binder points to. Here are some notes about Dmitries last year activity and my activity: http://haskell.org/haskellwiki/STG_in_Javascript -- vir http://vir.comtv.ru/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Another compilation problem
David Schonberger wrote: Another newbie question. To recap, running 6.6.1 on Vista. Fixed the other problem--lexical error, apparently a BOM added by Notepad--by getting Xemacs. Now when I type 'ghc -o hello hello.hs' at the prompt I get /gcc: installation problem, cannot exec 'as': no such file ro directory/. Any idea what's going on here or how to fix? Thanks. This is a bug in version 6.6.1, fixed in 6.8.1 (out shortly). See: http://hackage.haskell.org/trac/ghc/ticket/1110 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Blocked STM GC question
[Redirecting to GHC Users which is the right place for questions about GHC.] Yes, the garbage collector will (well, certainly should) find and kill such threads. By kill I mean that they get sent an asynchronous exception of some kind (I hope the documentation says which) so that the thread has a chance to clean up rather than being forcibly terminated. I'm not quite sure where this fact should be documented -- documentation for GHC itself, or for the STM library? -- but it surely should be somewhere. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Ashley Yakeley | Sent: 15 September 2007 21:39 | To: [EMAIL PROTECTED] | Subject: [Haskell] Blocked STM GC question | | If I have a thread that's blocked on an STM retry or TChan read, and | none of its TVars are referenced elsewhere, will it get stopped and | garbage-collected? | | I have in mind a pump thread that eternally reads off a TChan and | pushes | the result to some function. If the TChan is forgotten elsewhere, will | the permanently blocked thread still sit around using up some small | amount of memory, or will it be reaped by the garbage collector? | | -- | Ashley Yakeley | Seattle WA | | ___ | Haskell mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: STG to JavaScript translation
case e of b { pati - rhsi }
* evaluates 'e',
* binds the resulting value to 'b',
* performs case analysis on the result to find which alternative to choose
* binds the variables of the pattern to the components of the value
This is described in the GHC commentary:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType
does that help?
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Victor Nazarov
| Sent: 17 September 2007 11:48
| To: glasgow-haskell-users@haskell.org
| Subject: STG to JavaScript translation
|
| Hello.
| I'm working on the translation of GHC's STG language to
| JavaScript. I've started my implementation, but I've got stuck with
| the STG case statements. The problem is the binder in case expression.
|
| StgCase expr livevars liverhsvars bndr srt alttype alts
|
| Operationally, I need to save continuation and evaluate expr
| expression, but I have no idea what to do with the bndr. It seems to
| me that I need to build a closure binded by bndr with the body of
| expr evaluate it, update it, and use it in RHSs of alternatives.
| But It seems that this behavior isn't intended by GHC. Can you explain briefly
| how GHC implements this binder and what this binder points to.
|
| Here are some notes about Dmitries last year activity and my activity:
| http://haskell.org/haskellwiki/STG_in_Javascript
|
| --
| vir
| http://vir.comtv.ru/
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: compiling on solaris 9
On Mon, 2007-09-17 at 13:03 +0100, Simon Marlow wrote:
skaller wrote:
1. Measure the size (and alignment, while at it) of all the
integer types. (trial execute and run).
We already do this. Incedentally, the GHC RTS does provide a full
complement of explicitly-sized types: Stg{Int,Word}{8,16,32,64} which are
correct on all the platforms we currently support. The header that defines
them currently makes some assumptions (e.g. char is 8 bits), but that's
only because we're a bit lazy;
All good programmers are lazy -- the whole point of computers
is to automate things so we can be :)
The algorithm I presented (crudely) goes further.
What you're doing is enough for a language that doesn't have to
bind to C and/or C++.
Note that doesn't mean you can't generate C/C++, it means you don't
need to bind to existing libraries.
If you did, you need to do more work as described. For example
if there is a C lib requiring a
int*
argument .. there's no way to tell which one of your types,
if any, is aliased to it. Of course .. this only matters in
glue logic, i.e. when you're actually writing C/C++ code,
not if you're generating assembler/machine code and calling
the library directly using the platform ABI based on registers.
When writing glue logic the end user can fix this problem with
platform specific casts, but platform *independent* casts would
be better (e.g. you might cast StgInt32 pointer to long* on
Win64.. but that would make a corey mess if the glue logic
were compiled on Linux where long is 64 bits).
In Felix, this is critical, because the compiler actually generates
C++ which has to run on all platforms. I actually preferred the
same model you're using: (u)int{8,16,32,64} but it just didn't fly
because of the almost complete dependence on source code based
binding (Felix is roughly a well typed souped up macro processor .. :)
BTW: .. any thoughts on 128 bit integers? I mean, registers are
now 64 bits on desktops. There really should be a double precision
integer type..
--
John Skaller skaller at users dot sf dot net
Felix, successor to C++: http://felix.sf.net
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: STG to JavaScript translation
Hi
case e of b { pati - rhsi }
* evaluates 'e',
* binds the resulting value to 'b',
* performs case analysis on the result to find which alternative to choose
* binds the variables of the pattern to the components of the value
The Yhc.Core translator converts this to:
let b = e in case b of { pati - rhsi }
I'm not sure if that would be a clearer form for you to work with, as
it is closer to standard Haskell.
Thanks
Neil
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: STG to JavaScript translation
On Mon, 17 Sep 2007, Neil Mitchell wrote:
Hi
case e of b { pati - rhsi }
* evaluates 'e',
* binds the resulting value to 'b',
* performs case analysis on the result to find which alternative to choose
* binds the variables of the pattern to the components of the value
The Yhc.Core translator converts this to:
let b = e in case b of { pati - rhsi }
I'm not sure if that would be a clearer form for you to work with, as
it is closer to standard Haskell.
Definitely not, let allocates.
--
[EMAIL PROTECTED]
There is no magic bullet. There are, however, plenty of bullets that
magically home in on feet when not used in exactly the right circumstances.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
