[Timber] 64 bit?

[Johan Nordlander]

> Alright. I have the posix rts building successfully with no ptr size  
> mismatches. It also seems to be correct where the env uses the  
> timber generated C.
>
> The roadblock I'm at is where the generated code is unsafe. For  
> instance, switches for, what I'm guessing are empty list cases cast  
> a LIST ptr to an Int in a switch statement.. I'm guessing one could  
> address these kinds of issues in the kindle code by changing the  
> address to int cast use WORD instead of Int.  I haven't been able to  
> track down where this happens, (can someone who knows this code  
> better point me in the right direction?)

I've just checked in a patch in the darcs repo that does this (the  
main changes are in Prepare4C.hs).

> For now I have Int defined the same as WORD and have added the  
> appropriate BitOps for 64 bit. It compiles but there are still a  
> handfull (<10) warnings. I'll fix those in the morning and test.

Great!  Hope the casting patch helps.

Can you send a darcs patch bundle with the 64-bit changes when it works?

-- Johan

> On Sun, May 24, 2009 at 11:17 PM, Rick R <rick.richardson at gmail.com>  
> wrote:
> I've added a switch to define WORD in terms of architecture.  Now  
> I'm chasing down all of the ptr size mismatch warnings.  Most of the  
> time this is caused by casting to int (not Int), when I see such  
> cases, I assume it is safe to cast to WORD.
>
> Also, since this is supposed to be a bit of a bare metal run time  
> system, wouldn't it make sense to have Int match the size of the  
> architecture? It would remove a superfluous (IMO) abstraction.
>
>
> On Sun, May 24, 2009 at 10:54 AM, Johan Nordlander <johan.nordlander at ltu.se 
> > wrote:
> Some experiments have been made (although no code were checked in),  
> and they mostly involved fixing rts.h.  The underlying problem is,  
> though, that there's a risk parts of the code silently assume that  
> an Int is of the same size as a polymorphic parameter (that is, the  
> size of a pointer).  And ideally we would like to keep the Int size  
> at 32 bits in order to preserve platform independence, and introduce  
> an Int64 type for those cases this size is needed.
>
> So it's essentially a matter of searching the source code for any  
> such size dependencies, and perhaps also extended it with Int types  
> of other common sizes.  I can't foresee any deep technical  
> difficulies, it's just tedious work.
>
> You're welcome to give it a try!
>
> -- Johan
>
>
> I haven't looked too deeply into the source, but it would appear  
> that the bulk of the 64-bit problems are relegated to rts.h.
> Is there any effort under way to address this? If not, I will take a  
> whack at correcting it. If there is some experimental code out  
> there, I'd be happy to test it on my 64 bit fedora machine.
>
> -- 
> We can't solve problems by using the same kind of thinking we used  
> when we created them.
>   - A. Einstein
> _______________________________________________
> Timber mailing list
> Timber at haskell.org
> http://www.haskell.org/mailman/listinfo/timber
>
> _______________________________________________
> Timber mailing list
> Timber at haskell.org
> http://www.haskell.org/mailman/listinfo/timber
>
>
>
> -- 
> We can't solve problems by using the same kind of thinking we used  
> when we created them.
>    - A. Einstein
>
>
>
> -- 
> We can't solve problems by using the same kind of thinking we used  
> when we created them.
>    - A. Einstein
> _______________________________________________
> Timber mailing list
> Timber at haskell.org
> http://www.haskell.org/mailman/listinfo/timber