Custom Query (117 matches)
Results (10 - 12 of 117)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #46 | fixed | Shared libraries in GHC | none | simonmar@… |
| description |
GHC has some support for creating shared, dynamically linked, libraries, but it currently only works on MacOS X / PowerPC. The code to make it work on other platforms is partially there, we need somebody to push this through to completion. Shared libraries would mean that binaries get smaller, GHCi starts up more quickly, and plugins are easier amongst other things. DLLs on Windows are almost certainly rather easier than .so shared libraries on Linux, which go to great lengths to hide the existence of shared libraries from the programmer and end up with a great deal of complication as a result. Interested Mentors
Interested Students
|
|||
| #48 | fixed | Implement the semi-tagging optimisation in GHC | none | simonmar@… |
| description |
This is an optimisation idea for GHC. Currently when evaluating an expression that is the scrutinee of a case: case x of { ... } GHC jumps to the code for the x closure, which returns when x is evaluated. Commonly, x is already evaluated, and the code for an evaluated constructor just returns immediately. The idea is to encode the fact that a pointer points to an evaluated object by setting the LSB of the pointer. If the case expression detects that the closure is evaluated, it can avoid the jump and return, which are expensive on modern processors (indirect jumps). We can go a bit further than this, too. Since there are 2 spare bits (4 on a 64-bit machine), we can encode 4 (16) states. Taking 0 to mean "unevaluted", that leaves 3 (15) states to encode the values for the "tag" of the constructor. eg. an evaluated Bool would use 1 to indicate False and 2 to indicate True. An evaluated list cell would use 1 to indicate [] and 2 to indicate (:). The nice thing about the current approach is that code size is small; implementing the test and jump will certainly add extra code to compiled case expressions. But the gains might be worth it. Complexity-wise this means masking out these bits when following any pointer to a heap object, which means carefully checking most of the runtime. Interested Mentors
Interested Students
|
|||
| #54 | fixed | A model for client-side scripts with HSP | none | nibro@… |
| description |
HSP is a framework for writing dynamic web pages, with emphasis on server-side dynamics. It would be useful to also have a way to specify scripts that should be run on the client, e.g. by clever generation of JavaScript code through a combinator library. The point is to create a model that, to the programmer, looks and feels like Haskell, but that can be executed as JavaScript on the client. Interested Mentors
Interested Students
|
|||
