Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))

[malc]

On Fri, 11 Feb 2011, Blue Swirl wrote:

> On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini <address@hidden> wrote:
> > On 02/11/2011 06:05 AM, Rob Landley wrote:
> >>>
> >>> While this assumption works on QEMU's major hosts, it is not generally
> >>> true.
> >>
> >> It is generally true.  There is exactly one operating system that
> >> decided to go its own way, and the insane legacy reasons they did so are
> >> explained here:
> >>
> >>   http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
> >
> > Unix could do that because it had the luxury of having introduced 64-bit
> > when they already were using int=long=32.  So really nobody was using long
> > until 64-bit systems came along.  Windows instead has to deal with the
> > legacy of 16-bit, when long was the only 32-bit type.
> 
> IIRC also Unix was in that situation once (short = int =16, long = 32 bits).
> 
> > I have always agreed with you, but as much as I like LP64, I recently
> > changed my mind on this stance.  stdint.h means that there is _no reason_
> > why a program cannot be written portably so that it runs on both I32LP64 and
> > IL32LLP64 models.
> 
> Using intptr_t is not different from using long. There's also the
> advantage that it is a bit more specific.
> 
> > Someone has to do the work, of course, and it's surprising that two people
> > (Filip Navara and now Stefan) were brave enough to try it. :)  It has to be
> > a well-audited change though, not a quick attempt at making it work.
> 
> I'd still be interested to know if QEMU runs on win64. But even if it
> doesn't, changing longs to intptr_t and unsigned longs to uintptr_t is
> harmless enough that it should be applied nevertheless. Even if
> everybody stopped all win32/64 work after that, nothing would be lost
> except maybe some beauty in some beholder's eyes.
> 

Filips port did run on win64 last time i tried.

-- 
mailto:address@hidden