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@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@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@haskell.org
http://www.haskell.org/mailman/listinfo/timber

_______________________________________________
Timber mailing list
Timber@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