[Timber] 64 bit?

[Rick R]

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?)

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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/timber/attachments/20090525/cfd27461/attachment-0001.html