caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Bug?  Printf, %X and negative numbers
@ 2003-03-28 21:19 Brian Hurt
  2003-03-28 22:21 ` Yutaka OIWA
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Brian Hurt @ 2003-03-28 21:19 UTC (permalink / raw)
  To: Ocaml Mailing List


$ ocaml
        Objective Caml version 3.06

# Printf.printf "%08X\n" (1 lsl 30);;
C0000000
- : unit = () 
# Printf.printf "%010X\n" (1 lsl 30);;
00C0000000
- : unit = ()
# 

I expected output of 40000000, not C0000000.  Note that this isn't a case 
of simple sign extension, as the second example demonstrates.  Where'd the 
extra bit come from?

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 28+ messages in thread
* RE: [Caml-list] Bug?  Printf, %X and negative numbers
@ 2003-04-02 18:42 Gregory Morrisett
  2003-04-02 21:12 ` Ville-Pertti Keinonen
  2003-04-03  0:52 ` brogoff
  0 siblings, 2 replies; 28+ messages in thread
From: Gregory Morrisett @ 2003-04-02 18:42 UTC (permalink / raw)
  To: Ville-Pertti Keinonen, Andreas Rossberg; +Cc: caml-list

>For generic code, it obviously requires either boxing or specialized 
>versions of the code, as I suggested in a different message.

The TIL (and TILT) and MLTON compilers support untagged integers.
As you suggest (and Xavier well knows) the hard part is dealing
with polymorphic code of which there is a lot in ML.  Consider, for
instance, a function such as map -- whether it produces integer
cons-cells depends upon how map is instantiated.  Life gets
complicated when you don't have tags.  TIL/T solved this by 
passing type representations to polymorphic functions.  These
representations could be used to construct header words for
objects to indicate which fields were[n't] pointers.  The information
was also used to support unboxed doubles, and a few other things.
See my thesis for more information.  

While this approach is viable, it has a lot of costs.  For
some of the tradeoffs, I suggest reading Xavier's excellent 
paper in the 1998 Types in Compilation workshop.  

MLTON avoids these issues by specializing polymorphic code at
all of its uses so that it becomes monomorphic (not unlike C++), 
at the price of separate compilation.

Generics in C# go yet another route with runtime specialization
which has distinct advantages like the possibility of supporting
polymorphic recursion (see Andrew Kennedy & co's papers.)    
There are different tradeoffs here, due to features such as
reflection and "instanceof", etc.

In short, there's a wealth of literature on this subject.  
Ocaml has taken a very expedient approach and in my opinion,
it would be difficult to produce an alternative that 
achieves the same performance without introducing a lot
of complexity.  

-Greg

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 28+ messages in thread
* RE: [Caml-list] Bug?  Printf, %X and negative numbers
@ 2003-04-03  9:29 Fabrice Le Fessant
  0 siblings, 0 replies; 28+ messages in thread
From: Fabrice Le Fessant @ 2003-04-03  9:29 UTC (permalink / raw)
  To: Ville-Pertti Keinonen, Gregory Morrisett; +Cc: caml-list

 
> I agree that the OCaml runtime makes good compromises that 
> work well in practice.  Any added complexity would probably 
> hurt symbolic code, which seems to have had a high priority 
> in considerations of tradeoffs.

Just my two pence: in MLdonkey, int64 are used everywhere instead of
int, and instead of int32, which are two
small for file sizes. So, it will not benefit from any optimization on
int32. However, it would benefit 
from a new type 'long', that would be at-least a 63-bit integer.
Depending on the platform, this type could 
be implemented either by a traditionnal int (with the integer-bit set,
on 64-bit platforms), or by an int64 
on other platforms.

Since in the next years, more and more computers will be 64-bit, and
more and more applications will need 
support for integers in the range 33-bit ... 63-bit, this could be more
interesting than optimizing 32-bit 
integers (using the 'long' type, a program that would have used 32-bit
integers, would have the guaranty 
that the longs are not allocated on 64-bit platforms). Moreover, it can
probably be implemented in the 
Pervasives module without any changes in the compiler. But maybe int32
are already implemented by a normal int 
on 64-bit platforms ?


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2003-04-04 17:27 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-28 21:19 [Caml-list] Bug? Printf, %X and negative numbers Brian Hurt
2003-03-28 22:21 ` Yutaka OIWA
2003-03-30  9:51 ` Xavier Leroy
2003-03-31 15:44   ` Brian Hurt
2003-03-31 17:13     ` Ville-Pertti Keinonen
2003-04-01  8:19     ` Xavier Leroy
2003-04-01 16:09       ` David Brown
2003-04-01 16:45       ` Tim Freeman
2003-04-01 18:59         ` Brian Hurt
2003-04-01 19:16           ` Ville-Pertti Keinonen
2003-04-01 19:23             ` Tim Freeman
2003-04-01 21:00               ` Ville-Pertti Keinonen
2003-04-01 19:56             ` Brian Hurt
2003-04-01 20:45               ` Ville-Pertti Keinonen
2003-04-01 21:03                 ` Brian Hurt
2003-04-02  8:55             ` Andreas Rossberg
2003-04-02  9:20               ` Ville-Pertti Keinonen
2003-04-01 18:34       ` Ville-Pertti Keinonen
2003-04-02 11:44 ` Claude Marche
2003-04-02 18:42 Gregory Morrisett
2003-04-02 21:12 ` Ville-Pertti Keinonen
2003-04-02 21:46   ` Lauri Alanko
2003-04-03 17:40     ` Ville-Pertti Keinonen
2003-04-04 16:14   ` Brian Hurt
2003-04-04 17:14     ` Ville-Pertti Keinonen
2003-04-04 17:27     ` Falk Hueffner
2003-04-03  0:52 ` brogoff
2003-04-03  9:29 Fabrice Le Fessant

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).