I see. I'm happy to implement whatever we come up with. I have no experience, however, in language design. I would certainly like to come up with a method for representing large scalars, but I haven't a clue as to a solution that would be elegant and flexible in the face of change. The only one is, as you mentioned, boxing. However, that seems to cancel out the whole point of compiling to efficient C code. <br>
<br>I can build a new patch which will lock Int at 32 bit. That isn't a problem. Compiling on 64 bit machines and maintaining consistent behavior is good enough for now. <br><br>I am traveling for a bit and am not sure that I can accomplish much on my macbook. I'll see what I can do. <br>
<br><div class="gmail_quote">On Thu, Jun 4, 2009 at 7:57 AM, Johan Nordlander <span dir="ltr"><<a href="mailto:johan.nordlander@ltu.se">johan.nordlander@ltu.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are two issues here.<br>
<br>
Firstly, I think the strategy should be to identify the purely rts-internal uses of Int that really ought to be platform-dependent, or rather to match the size of pointers. I don't think there are too many of these, as most uses of Int in the current .c files correspond to the Timber type Int which we really want to keep at 32 bits on all platforms (see my arguments in the quoted text below on why platform-independent Int semantics is a good thing). This makes the majority of the Int->WORD changes in the patch go in the wrong dorection, I think, although I'm sure that some changes are indeed called for (where the rts uses internal loop counters, for example). For the same reason one should unconditionally typedef Int as a int32_t in rts.h, in contrast to the definition of WORD which may vary between platforms.<br>
<br>
Secondly, while the addition of a BITS64 type is both desirable and principally correct, we have an implementation problem that must be resolved before such a type can be safely supported on platforms with pointers smaller than 64 bits. The problem occurs because polymorphic values are implemented as void pointers in the C code, and all concrete values (heap allocated values as well as scalars) are assumed to be castable to void pointers without loss of information. This is the main reason why we don't yet support the Double type, or target platforms with pointer sizes less than 32 bits. However, there are known solutions to this problem (e.g., using boxing as a last resort, perhaps in combination with code specialization), we just haven't investigated which approach that would suit us best.<br>
<br>
So for the time being I'm reluctant to check in the patch, as it would make the platform-dependent Int semantics even more manifest and lead to incorrect results when BITS64 values are used with polymorphic functions or data structures. A patch that fixes the Int type to int32_t but changes all internal counters etc to use WORD would be more useful at this stage. Then we could try to devise a implementation technique for polymorphism with big scalars in general, which would make the addition of a BITS64 type (as well as Double and even Int64) straightforward.<br>
<br>
That said, I see no reason why the proposed patch should work on a 64-bit machine. So if you just want to get past the type error, you should change the type signature for showh to<br>
<br>
showh :: a -> Int -> String \\ BitsOp a<br>
<br>
The reason being that showh doesn't work for any choice of type a, just the choices for which there exists a BitsOp instance.<br>
<br>
-- Johan<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
-- this message was sent to the moderators due to size constraints, so I'm resending it, this time with a gzipped attachment.<br>
Sorry for the slow response. Been slammed at work, can only work on this on the weekends recently.<br>
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.<br>
<br>
I have attached the darcs patch for my repository.<br>
<br>
I changed showh / showHex to this:<br>
<br>
showh :: a -> Int -> String<br>
showh a 0 = ""<br>
showh a n = ( hex (toInt((a `bsrl` (4 * n1)) `band` 0xF)) ) : str<br>
where n1 = n - 1<br>
str = showh a n1<br>
<br>
typeclass ShowHex a where<br>
showhex :: a -> String<br>
<br>
instance showHBits64 :: ShowHex BITS64 where<br>
showhex a = "0x" ++ showh a 16<br>
<br>
instance showHBits32 :: ShowHex BITS32 where<br>
showhex a = "0x" ++ showh a 8<br>
<br>
instance showHBits16 :: ShowHex BITS16 where<br>
showhex a = "0x" ++ showh a 4<br>
<br>
instance showHBits8 :: ShowHex BITS8 where<br>
showhex a = "0x" ++ showh a 2<br>
<br>
<br>
But get the error:<br>
Type error close to line 182, column 9<br>
Cannot solve typing constraint BitsOp a<br>
<br>
<br>
<br>
On Tue, May 26, 2009 at 3:05 PM, Johan Nordlander <<a href="mailto:johan.nordlander@ltu.se" target="_blank">johan.nordlander@ltu.se</a>> wrote:<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
-- Johan<br>
<br>
<br>
On Sun, May 24, 2009 at 10:54 AM, Johan Nordlander <<a href="mailto:johan.nordlander@ltu.se" target="_blank">johan.nordlander@ltu.se</a>> wrote:<br>
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.<br>
<br>
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.<br>
<br>
You're welcome to give it a try!<br>
<br>
-- Johan<br>
<br>
<br>
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.<br>
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.<br>
<br>
-- <br>
We can't solve problems by using the same kind of thinking we used when we created them.<br>
- A. Einstein<br>
_______________________________________________<br>
Timber mailing list<br>
<a href="mailto:Timber@haskell.org" target="_blank">Timber@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/timber" target="_blank">http://www.haskell.org/mailman/listinfo/timber</a><br>
<br>
_______________________________________________<br>
Timber mailing list<br>
<a href="mailto:Timber@haskell.org" target="_blank">Timber@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/timber" target="_blank">http://www.haskell.org/mailman/listinfo/timber</a><br>
<br>
<br>
<br>
-- <br>
We can't solve problems by using the same kind of thinking we used when we created them.<br>
- A. Einstein<br>
_______________________________________________<br>
Timber mailing list<br>
<a href="mailto:Timber@haskell.org" target="_blank">Timber@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/timber" target="_blank">http://www.haskell.org/mailman/listinfo/timber</a><br>
<br>
_______________________________________________<br>
Timber mailing list<br>
<a href="mailto:Timber@haskell.org" target="_blank">Timber@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/timber" target="_blank">http://www.haskell.org/mailman/listinfo/timber</a><br>
<br>
<br>
<br>
-- <br>
"The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge."<br>
- Daniel J. Boorstin<br>
<br>
<br>
<br>
<br>
-- <br>
"The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge."<br>
- Daniel J. Boorstin<br>
<br></div></div>
<64bit.diff.gz>_______________________________________________<div class="im"><br>
Timber mailing list<br>
<a href="mailto:Timber@haskell.org" target="_blank">Timber@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/timber" target="_blank">http://www.haskell.org/mailman/listinfo/timber</a><br>
</div></blockquote><div><div></div><div class="h5">
<br>
_______________________________________________<br>
Timber mailing list<br>
<a href="mailto:Timber@haskell.org" target="_blank">Timber@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/timber" target="_blank">http://www.haskell.org/mailman/listinfo/timber</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>"The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge." <br>- Daniel J. Boorstin<br>
<br>