Sorry for the slow response. Been slammed at work, can only work on this on
the weekends recently.
I have made changes to allow for 64 bit everywhere. I have made what I think
might be a fix to BitOps but I can't get it to compile.
I have attached the darcs patch for my repository.
I changed showh / showHex to this:
showh :: a -> Int -> String
showh a 0 = ""
showh a n = ( hex (toInt((a `bsrl` (4 * n1)) `band` 0xF)) ) : str
where n1 = n - 1
str = showh a n1
typeclass ShowHex a where
showhex :: a -> String
instance showHBits64 :: ShowHex BITS64 where
showhex a = "0x" ++ showh a 16
instance showHBits32 :: ShowHex BITS32 where
showhex a = "0x" ++ showh a 8
instance showHBits16 :: ShowHex BITS16 where
showhex a = "0x" ++ showh a 4
instance showHBits8 :: ShowHex BITS8 where
showhex a = "0x" ++ showh a 2
But get the error:
Type error close to line 182, column 9
Cannot solve typing constraint BitsOp a
On Tue, May 26, 2009 at 3:05 PM, Johan Nordlander
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.
It is reasonable, although the big drawback is that the meaning of programs will then be platform-dependent in a very unfortunate way. For example, the expression 60000 + 10000 > 60000 will be true on some platforms but false on 16-bit architectures. I have no problem with the wrap-around semantics for integers (it's what we want!), but it should be specified by the language to mean the same thing on all platforms. Programs written with the specific aim to fit well on smaller/bigger architectures should instead indicate this by using integer types with other wrap-around limits (we ought to add Int8, Int16 and Int64 as primitives).
Using the machine-dependent WORD type when casting to and from pointers is a different thing -- this change doesn't affect the meaning of any Timber programs.
-- Johan
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 _______________________________________________ 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
-- "The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge." - Daniel J. Boorstin