Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On Feb 11, 2011, at 1:47 PM, Paolo Bonzini wrote: ps: HP-UX also uses IL32 on ia64. Now _that_ is hard to understand. Backward compatibility with hppa... VMS also uses IL32 on alpha and ia64, but it has both P32 and P64.
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini pbonz...@redhat.com 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.
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
On Fri, 11 Feb 2011, Blue Swirl wrote: On Fri, Feb 11, 2011 at 2:47 PM, Paolo Bonzini pbonz...@redhat.com 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:av1...@comtv.ru
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
Stefan Weil w...@mail.berlios.de writes: Am 07.02.2011 08:23, schrieb Markus Armbruster: Stefan Weil w...@mail.berlios.de writes: Am 05.02.2011 16:35, schrieb Blue Swirl: [...] The patch changes also signed longs to uintptr_t. That could introduce regressions, so please use signed/unsigned as original. I changed the code manually, and there was only one location where signed/unsigned made a difference. That single case was an int parameter passed in a void pointer, and I used intptr_t there. I had the impression that in the current code (long) was sometimes used because it is shorter than (unsigned long) :-) As long as changes are made manually with the necessary care, I'd recommend using uintptr_t where possible. I'd recommend not to mix up the intptr portability clean up with the signedness cleanup. Much easier to review separately. Moreover, cleaning up signedness changes generated code, while cleaning up the types shouldn't (except on hosts where the code doesn't work). Testable, just don't forget to strip the debug info. [...] Markus, your recommendation is ok for modifications which change the generated code or which need more context for the review. I don't think that you will have any problem with reviewing signedness changes like these ones: -#define saddr(x) (uint8_t *)(long)(x) -#define laddr(x) (uint8_t *)(long)(x) +#define saddr(x) (uint8_t *)(uintptr_t)(x) +#define laddr(x) (uint8_t *)(uintptr_t)(x) Neither of these changes changes the binary code for the commonly used hosts, and the patch does not need further context for the review. I intend to split my patch in three parts: * one for tcg_gen_exit_tb calls which will be modified as Blue Swirl has suggested * one for the parameter passing of a signed value via pointer * one for the rest which contains only a handful of trivial signedness changes, all following the same pattern like the example given above Is that ok? Let's see the patches :)
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
Am 07.02.2011 08:23, schrieb Markus Armbruster: Stefan Weil w...@mail.berlios.de writes: Am 05.02.2011 16:35, schrieb Blue Swirl: [...] The patch changes also signed longs to uintptr_t. That could introduce regressions, so please use signed/unsigned as original. I changed the code manually, and there was only one location where signed/unsigned made a difference. That single case was an int parameter passed in a void pointer, and I used intptr_t there. I had the impression that in the current code (long) was sometimes used because it is shorter than (unsigned long) :-) As long as changes are made manually with the necessary care, I'd recommend using uintptr_t where possible. I'd recommend not to mix up the intptr portability clean up with the signedness cleanup. Much easier to review separately. Moreover, cleaning up signedness changes generated code, while cleaning up the types shouldn't (except on hosts where the code doesn't work). Testable, just don't forget to strip the debug info. [...] Markus, your recommendation is ok for modifications which change the generated code or which need more context for the review. I don't think that you will have any problem with reviewing signedness changes like these ones: -#define saddr(x) (uint8_t *)(long)(x) -#define laddr(x) (uint8_t *)(long)(x) +#define saddr(x) (uint8_t *)(uintptr_t)(x) +#define laddr(x) (uint8_t *)(uintptr_t)(x) Neither of these changes changes the binary code for the commonly used hosts, and the patch does not need further context for the review. I intend to split my patch in three parts: * one for tcg_gen_exit_tb calls which will be modified as Blue Swirl has suggested * one for the parameter passing of a signed value via pointer * one for the rest which contains only a handful of trivial signedness changes, all following the same pattern like the example given above Is that ok? Regards, Stefan
Re: [Qemu-devel] Re: Porting QEMU to new hosts with unusual ABI (sizeof(long) != sizeof(void *))
Stefan Weil w...@mail.berlios.de writes: Am 05.02.2011 16:35, schrieb Blue Swirl: [...] The patch changes also signed longs to uintptr_t. That could introduce regressions, so please use signed/unsigned as original. I changed the code manually, and there was only one location where signed/unsigned made a difference. That single case was an int parameter passed in a void pointer, and I used intptr_t there. I had the impression that in the current code (long) was sometimes used because it is shorter than (unsigned long) :-) As long as changes are made manually with the necessary care, I'd recommend using uintptr_t where possible. I'd recommend not to mix up the intptr portability clean up with the signedness cleanup. Much easier to review separately. Moreover, cleaning up signedness changes generated code, while cleaning up the types shouldn't (except on hosts where the code doesn't work). Testable, just don't forget to strip the debug info. [...]
