FW: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Jay K <jay dot krell at cornell dot edu>]

[this time as plain text, sorry]
 




> Date: Fri, 15 Jun 2012 19:58:23 +0000
> From: joseph  

> To: tromey  
> CC: ebotcazou palves gcc-patches gingold rth mikestump 
> Subject: Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)
> 
> On Fri, 15 Jun 2012, Tom Tromey wrote:
> 
> > HOST_WIDE_INT is also not very persuasive to me. We did many things in
> 
> Although HOST_WIDE_INT is used for too many different things (see Diego's 
> and my architectural goals documents for more discussion, specifically 
> "HOST_WIDE_INT, HOST_WIDEST_INT and associated concepts" at the bottom of 
> the conventions document), I don't think we should use "long long" 
> directly in the compiler (except in limited places such as hwint.h 
> selecting a type to use for some abstraction) simply because it's not the 
> right abstraction for saying what the requirements are on the type being 
> used. If the requirement is "at least 64 bits", int_fast64_t would be 
> better, for example (gnulib can generate a stdint.h where the host doesn't 
> have it). If it's "big enough for the target address space" then 
> HOST_WIDE_INT is what we have at present. If it's "fast on the host, but 
> size doesn't matter", then HOST_WIDEST_FAST_INT.
> 
> -- 
> Joseph S. Myers
> joseph@

 
 
 
 
 > If it's "fast on the host, but size doesn't matter", then HOST_WIDEST_FAST_INT 



 
That is int, right? I guess sometimes long, 64bit integer might be faster on 64bit host that has 32bit int??
 For a local variables, the size difference rarely amounts to much, I think. For data structures that you have many of, size optimizations become interesting. 



 
One can easily dream up many abstractions, too many: 



 
  can at least hold host pointer 
can at least hold target pointer 
can hold the size of a target struct, 32 bits is ok with slightly degraded functionality if 64bits aren't available 
can be a loop index for a certain smallish constant number of iterations -- e.g. what to use for (pass = 0; pass < 2;) or for (i = 0; i < sizeof(integer type);) 
can hold source file size or offset, or seek delta (possibly negative?) 
can hold host object file file size or offset, or seek delta (possibly negative?) 
can hold target object file file size or offset, or seek delta (possibly negative?) 
can hold host executable file file size or offset, or seek delta (possibly negative?) 
can hold target executable file file size or offset, or seek delta (possibly negative?) 
can hold host library/archive file file size or offset, or seek delta (possibly negative?) 
can hold target library/archive file file size or offset, or seek delta (possibly negative?) 
can hold the number of members in a library/archive, or seek delta (possibly negative?) 
can hold the number of files in a directory (e.g. for #include search caching) 
can hold the number of files seen in preprocessor run 
number of instructions in a function (held in memory or in a file?) 
number of basic blocks in a function (held in memory or in a file?) 
number of <something> that is held in a file (same as file size generally) 
number of <something> that is held in memory (size_t) 
number of cycles measured or estimated 
number of bytes allocated 
number of bytes allocated minus number of bytes freed 
length of an in-memory string (size_t strlen(), but rarely does 32bits not suffice) 


One can even imagine a 53bit-mantissa double being used...but after some thought in my own code, I'd really rather depend on their being a 64bit integer. 


It is tempting to "throw up one's hands" in disgust and just smush all the abstractions down to almost nothing. 
Otherwise you have to worry about if the types interoperate well, which one is larger/smaller than the other, how do I safely convert? Are their symbols for the min/max of each type?
 int is always at least 32bits on modern hosts and "reasonable" if not theoretical max for many things.
 ditto long, but is really definitely at least 32bits, and often larger 
similarly HOST_WIDE_INT is pretty fast, maybe slower, often 64bits, and 64bits is usually vastly sufficient for vastly most things..unless manipulating floating point pieces.... 
One can check for overflow so that if a 32bit integer proves too small, there is a clear error instead of silent wraparound and crash or bug. One could encode such overflow checks into a C++ integer-like class with operator overloading. It's not that difficult..
 



Or just provide the stdint.h fast/atleast/exact types and let every "section" of code make its own typedefs thereof. 
Establish a naming convention perhaps such that when I see foo_t, I know at a glance that is "just some integer type".
Maybe by always putting "size" or "count" in the name?
But some things are pervasive -- host/target address sizes/offsets. 



I need to go read the document..


 


 
 - Jay