On Jul 25, 2007, at 3:48 AM, Simon Marlow wrote:
Peter Tanski wrote:
Simon Marlow wrote:
Joe Buehler wrote:
What is the purpose of RESERVED_C_STACK_BYTES? Are stg routines
expecting a free area of that size at *top* of stack? I need to
make sure
that I have saved the registers at the correct end of the stack
frame created
in StgRun. It is difficult to tell from the existing hppa code
what exactly
was intended.
I had the same problem. I think you can define
USE_MINIINTERPRETER (in rts/Makefile:STANDARD_OPTS or as
build.mk:SRC_CC_OPTS) and that will get around StgCRun/Return.
The problem I had was finding out where everything was supposed to
go: I needed to see the actual C compiler output to make sure
things were safe. In the end I gave up--Windows-native RTS is
unregisterised for now because CL cannot create Explicit Register
Variables or use the 'register' storage class for global variables
(both are used in includes/Regs.h).
yikes! Really? I can't see a good reason that you need to force
unregisterised compilation at all. GHC is compiling to native
code, the C compiler isn't involved. If the sticking point is just
StgCRun.c, then code up that little fragment in assembler instead,
it's only a handful of instructions.
That was my orignial solution but I have to look at the output from
gcc, not simply parrot the inline assembler (not hard--I was hoping
you might be able to explain how things fit together there).
Unfortuantely the REG(x) variables are also a problem. Just another
bump in the road, I guess but not entirely trivial--those REG(x) vars
are global so they thread through libHS
Speaking of 'bumps', I think cl may not be the best replacement for
cpp. In another email I noted how cl does not have a '-traditional'
operation that restricts the recognition of '#' to column 0 so I had
to move things like "^ *#-}" back a line. Last night I discovered
two things:
(1) you need to pass cl the 'preserve comments' flag (/C) or it eats C
++ style comment tokens like the (//) infix function in Array.hs; and,
(2) defines such as this one in $(TOP)/libraries/base/include/
CTypes.h:198:201:
#define INSTANCE_READ(T,B) \
instance Read T where { \
readsPrec = unsafeCoerce# (readsPrec :: Int -> ReadS B); \
readList = unsafeCoerce# (readList :: ReadS [B]); }
would need to be reformatted. (CL's preprocessor errors out for '#'
at the end of 'unsafeCoerce#' because it recognises '#' as the
stringification ("stringizing") operator and expects a parameter
immediately after: error C2162.) Escaping it, as in:
#define INSTANCE_READ(T,B) \
instance Read T where { \
readsPrec = unsafeCoerce\# (readsPrec :: Int -> ReadS B); \
readList = unsafeCoerce\# (readList :: ReadS [B]); }
does not work since it will only output the escaped sequence:
... instance Read CInt where { readsPrec = unsafeCoerce\#
(readsPrec :: Int -> ReadS Int32); ...
I haven't seen any note that Template Haskell does not now require
linking the TH library every time (it wouldn't have been built by the
time base needs to be rebuilt, anyway) but that might be a solution.
If GHC intends to keep cpp, it might be better for me to find a cpp
tool and embed that in the compiler. As it is, CL's cpp outputs
[basename].i files in the current directory where you are running the
compiler and I need to renameFile them to the intended output file;
this works well but it would not be a nice surprise should you lack
write access to your current working directory. I would rather pipe
the output directly to GHC (a nice optimisation--no tmp file unless '-
keep-tmp-files' is in play).
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
