[Haskell] ANNOUNCE: Harpy 0.4 - Runtime code generation for x86 machine code
We are pleased to announce the release of Harpy 0.4, a library for runtime code generation for x86 machine code. Harpy is available from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy-0.4 Also see Harpy's homepage, which features two tutorials and access to the darcs repo (and to the Haddock documentation, until it is available from Hackage, too): http://uebb.cs.tu-berlin.de/harpy/ Harpy is supposed to be built with GHC 6.8 and GHC 6.6 (with Cabal 1.2 or greater). Please report any build problems you encounter. This release features the following additions and fixes: - New convenience top-level module "Harpy", which re-exports Harpy.CodeGenMonad, Harpy.Call and Harpy.X86Assembler - It is now possible to override Harpy's automatic code buffer management. The new field 'customCodeBuffer' in the type 'CodeGenConfig' can be set to 'Just (buf, size)', where 'buf' is a pointer to a memory region of 'size' bytes. Harpy will then use the supplied code buffer and will not perform any automatic code buffer allocation on overflow. Overflow checking is still performed and will result in an exception in the CodeGen monad. - When using the high-level assembler in X86Assembler, the code buffer is automatically protected from overflow. - Floating point operations added to X86Assembler (only for double operands yet). - Preliminary support for SSE instructions. Currently, only the packed and scalar floating-point arithmetic operations are supported (both in the low-level module Harpy.X86CodeGen and as methods in Harpy.X86Assembler) - Code buffer default size has been increased from 128 to 4096 bytes. - The CodeGenMonad fails when a label is defined twice. - It is now possible to associate names with labels, using the new operation newNamedLabel. The given names will show up in the disassembly, which makes debugging of generated code much easier. - The doc directory contains a second, slightly larger tutorial now. - The examples/evaluator directory contains a small example interpreter for arithmetic expressions, which translates expressions entered at the keayboard to machine code on the fly. This is the demo program we presented at the Haskell Workshop 2007. Happy Haskell Hacking with Harpy, Martin and Dirk signature.asc Description: OpenPGP digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Harpy -- run-time code generation library
Florian Weimer schrieb: > * Martin Grabmueller: > >> For the future, we'd like to be able to support more architectures, >> but it's not very high on our priority list. Maybe interest >> of others could change that... > > LLVM as a target could be interesting as well, and would avoid the > need to write tons of optimizers. [Sorry for the delay.] LLVM is indeed interesting, but has several drawbacks: - written in C++ (we don't have experience in interfacing Haskell and C++) - has been used with imperative languages yet, no experience available on using it for FP. - rather large system - and finally, I have to admit: a bit of Not Invented Here One of our goals was indeed to have a Haskell-only code generator, which has the advantage that it is easier to install, use and distribute. Regards, Martin signature.asc Description: OpenPGP digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Harpy -- run-time code generation library
Anatoly Yakovenko schrieb: > Any plans for ARM/Thumb machine code generation? Currently: no. It would be possible to support other architectures by adding appropriate backend modules, but currently, the library is not really prepared for that. One reason is that we only develop for x86-machines (and don't own any ARM machines). The other is that currently more than 90% of the code are machine-dependant. For the future, we'd like to be able to support more architectures, but it's not very high on our priority list. Maybe interest of others could change that... Best regards, Martin signature.asc Description: OpenPGP digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: Harpy -- run-time code generation library
apfelmus schrieb: > Also, the explicit declaration of labels has an inherent safety problem. > Namely, nobody prevents you from using a label twice, like for example in > > loopStart @@ mul exc > ... > loopStart @@ cmp ecx (0 :: Word32) Your are right. In the next version, Harpy *will* prevent you from defining a label twice. It was just an oversight on my part not to check for duplicate definitions. Thanks for spotting this problem. Martin signature.asc Description: OpenPGP digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Problem with types.
Szymon Ząbkiewicz wrote:
> Hi!
> I'm new to Haskell and FP so i've got some problems. I wrote this code :
>
> getNr :: Int -> Int
> getNr x = do
> putStrLn ("enter " ++ x ++ " number:")
> nr <- getLine
> return nr
>
> And when I try to load it to GHCi I get an error (there is also plenty
> of others but they look the same):
There are several problems with this code:
1. You are using (++) to concatenate strings and the value x, which
is of type Int. Use 'show' to convert numbers to strings.
2. The result type of getNr is Int, but the body of the function is
a do expression, which is always a monadic value. Since you use
the input/output operations putStrLn and getLine, the type of
the function must be Int -> IO Int
3. The return value of getLine is a string, but you try to return
it from the function, which (see 2) has a return value of IO Int.
Use 'read' to convert the string to an integer value.
HTH,
Martin
signature.asc
Description: OpenPGP digital signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Strange "let"
Jinwoo Lee wrote: Hi, I'm a Haskell newbie. I was trying several things with GHCi and found out that the expression "let a + b = 3" does not generate any errors. Prelude> let a + b = 3 Try this: Prelude> let a + b = 3 Prelude> 5+11 3 Your `let a+b=3' has redefined `+' to be a function always evaluating to 3. `a' and `b' are formal parameters of the newly defined function. Martin ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
