Re: tidy binaries

On 5/27/05, Charlie <[email protected]> wrote:
> At 06:51 AM 5/26/2005 -0700, Cory Nelson wrote:
> >Yup, Win64.  A ptr_type would be the easiest way out.  FYI, VC++
> >defines intptr_t and uintptr_t in stddef.h.
> 
> Good to know.  I.e. are these ISO C standard?  I'll check out what Solaris
> supports at work today.  Anyone have access to other *nix boxes to verify
> the local equivalents?

I believe it is ANSI C, but I could be wrong.

> >It would be nice to avoid this entirely and do a union { char *s; int
> >i; } when storing options, though from trying to make these changes
> >myself it quicky got overwhelming as there are many blocks that depend
> >on it being a ulong.
> 
> My dim recollection is that I tried that to start and backed off because of
> hassles with static initialization in config.c.
> 
> 
> >The errors with user-defined structs (user data, TidyInputSource,
> >TidyOutputSink) were all quick fixes.
> 
> OK, saw that in the diffs.  Surprised the Alpha compiler didn't complain
> about these.  Good catch.
> 
> But this raises a general question about 64-bit pointers: in a program that
> would fit into a 32-bit memory model, is it safe to lose the upper 32-bits
> of pointer values?  Probably not in general.  I suppose some CPUs might
> implement a segmented scheme (like the 8086 of old) vs. a flat, linear
> address space.

I believe I heard talk of a (maybe compiler?) switch for win64 that
sets "only use this below 64-bit".

> 
> > > For the record, the types ulong, uint, etc. are pre-defined for many Unix
> > > compilers.
> >
> >That's understandable, as some platforms differ in size.  But pointers
> >I still can't understand :)
> 
> I don't get why "long" is ever different than a pointer size
> either.  Perhaps MS gets better performance using 32-bit values even on a
> 64-bit CPU.  When you really need a large integer, you have to ask for it.
> 
> However, there is nothing platform-specific about how the TidyLib configs
> work.  Nor is anything wired to a particular size.  Currently, the only
> assumption is that sizeof(long) == sizeof(char*).  A safer way to express
> this in the source might be sizeof(uintptr_t) == sizeof(char*) and
> sizeof(uintptr_t) >= size(ulong).
> 
> Perhaps the old standby void* would be best of all.
> 
> 
> 
> > > At 04:21 AM 5/23/2005 -0700, Cory Nelson wrote:
> >As an additional note, the standard calling convention for WIN64 is
> >__fastcall, so the TIDY_CALL code should probably be changed:
> >
> >#ifndef TIDY_CALL
> >#if defined(_WIN64) // note _WIN32 will also be defined, so we must
> >test _WIN64 first.
> >#define TIDY_CALL __fastcall
> >#elif defined(_WIN32)
> >#define TIDY_CALL __stdcall
> >#else
> >#define TIDY_CALL
> >#endif
> >#endif
> 
> Is __fastcall the compiler default on WIN64?  If so, there is no need to
> set it explicitly.  If not, perhaps this is better handled in the
> build.  Does anyone use TIDY_CALL for .NET or other wrappers on Win64?

yup, it is.  but it needs to be there for the same reason __stdcall is
set- if your project is compiling for some other calling convention,
and you want to use a pre-build DLL.

> Sorry asking so many dumb questions about 64-bit code and Win64 in
> particular.  But I have not had a chance to work with either yet.  I
> appreciate your knowledge on this, Cory.
> 
> take it easy,
> Charlie
> 
> 
> 


-- 
Cory Nelson
http://www.int64.org


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005