Menu
▾
▴
nasm-devel
|
From: H. P. A. <hp...@zy...> - 2013-12-10 05:55:33
|
On 12/07/2013 10:12 AM, nasm-bot for Cyrill Gorcunov wrote: > Commit-ID: 71f71c0dbe204d8d6a58e695c038bf0508d3b406 > Gitweb: http://repo.or.cz/w/nasm.git?a=commitdiff;h=71f71c0dbe204d8d6a58e695c038bf0508d3b406 > Author: Cyrill Gorcunov <gor...@gm...> > AuthorDate: Sat, 7 Dec 2013 16:12:07 +0400 > Committer: Cyrill Gorcunov <gor...@gm...> > CommitDate: Sat, 7 Dec 2013 16:12:07 +0400 > > iflag: Introduce IFLAG_INIT helper > No, this once again introduces an unnecessary C99ism, which we really are trying to avoid. -hpa |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 06:23:17
|
We only require that there is a supported 64-bit integer type. Cyrill Gorcunov <gor...@gm...> wrote: >On Mon, Dec 09, 2013 at 09:55:10PM -0800, H. Peter Anvin wrote: >> On 12/07/2013 10:12 AM, nasm-bot for Cyrill Gorcunov wrote: >> > Commit-ID: 71f71c0dbe204d8d6a58e695c038bf0508d3b406 >> > Gitweb: >http://repo.or.cz/w/nasm.git?a=commitdiff;h=71f71c0dbe204d8d6a58e695c038bf0508d3b406 >> > Author: Cyrill Gorcunov <gor...@gm...> >> > AuthorDate: Sat, 7 Dec 2013 16:12:07 +0400 >> > Committer: Cyrill Gorcunov <gor...@gm...> >> > CommitDate: Sat, 7 Dec 2013 16:12:07 +0400 >> > >> > iflag: Introduce IFLAG_INIT helper >> > >> >> No, this once again introduces an unnecessary C99ism, which we really >> are trying to avoid. > >Wait, Peter, don't we require the compiler to support C99? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
|
From: Cyrill G. <gor...@gm...> - 2013-12-10 06:30:44
|
On Mon, Dec 09, 2013 at 10:22:52PM -0800, H. Peter Anvin wrote: > We only require that there is a supported 64-bit integer type. I see. And I'm wondered -- is there some old compiler which is used for nasm building but doesn't support c99? I mean it's 2k13 already and c99 is pretty known standart, maybe we could stick to it? |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 06:37:42
|
You realize that MSVC still doesn't support most C99 feature, right? Scary but true. Cyrill Gorcunov <gor...@gm...> wrote: >On Mon, Dec 09, 2013 at 10:22:52PM -0800, H. Peter Anvin wrote: >> We only require that there is a supported 64-bit integer type. > >I see. And I'm wondered -- is there some old compiler which is >used for nasm building but doesn't support c99? I mean it's >2k13 already and c99 is pretty known standart, maybe we could >stick to it? -- Sent from my mobile phone. Please pardon brevity and lack of formatting. |
|
From: Cyrill G. <gor...@gm...> - 2013-12-10 06:39:57
|
On Mon, Dec 09, 2013 at 10:37:10PM -0800, H. Peter Anvin wrote: > You realize that MSVC still doesn't support most C99 feature, right? > Scary but true. I see :( That's pity. I'll update the patch. |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 06:39:27
|
Similarly, OpenWatcom only supports a subset of C99 features... although we no longer build OS/2 binaries as part of the standard build... ;) Cyrill Gorcunov <gor...@gm...> wrote: >On Mon, Dec 09, 2013 at 10:22:52PM -0800, H. Peter Anvin wrote: >> We only require that there is a supported 64-bit integer type. > >I see. And I'm wondered -- is there some old compiler which is >used for nasm building but doesn't support c99? I mean it's >2k13 already and c99 is pretty known standart, maybe we could >stick to it? -- Sent from my mobile phone. Please pardon brevity and lack of formatting. |
|
From: Dave Y. <dav...@gm...> - 2013-12-10 07:45:06
|
On 12/09/13 10:38 pm, H. Peter Anvin wrote: > Similarly, OpenWatcom only supports a subset of C99 features... although we no longer build OS/2 binaries as part of the standard build... ;) I build on OS/2 with configure and make using GCC 4.4.6 now as the OW built binaries are subtly broken (fail 4 out of a couple of hundred H264 conformance tests). BTW, the build (2.11rc4) currently dies here after linking nasm.exe and ndisasm.exe with false -b docbook -d manpage -o nasm.xml nasm.txt make: *** [nasm.xml] Error 1 due to no asciidoc or xmlto packages installed here. Dave > > Cyrill Gorcunov<gor...@gm...> wrote: >> On Mon, Dec 09, 2013 at 10:22:52PM -0800, H. Peter Anvin wrote: >>> We only require that there is a supported 64-bit integer type. >> >> I see. And I'm wondered -- is there some old compiler which is >> used for nasm building but doesn't support c99? I mean it's >> 2k13 already and c99 is pretty known standart, maybe we could >> stick to it? > |
|
From: Cyrill G. <gor...@gm...> - 2013-12-10 07:54:19
|
On Mon, Dec 09, 2013 at 11:44:36PM -0800, Dave Yeo wrote: > On 12/09/13 10:38 pm, H. Peter Anvin wrote: > > Similarly, OpenWatcom only supports a subset of C99 features... although we no longer build OS/2 binaries as part of the standard build... ;) > > I build on OS/2 with configure and make using GCC 4.4.6 now as the OW > built binaries are subtly broken (fail 4 out of a couple of hundred H264 > conformance tests). > BTW, the build (2.11rc4) currently dies here after linking nasm.exe and > ndisasm.exe with > false -b docbook -d manpage -o nasm.xml nasm.txt > make: *** [nasm.xml] Error 1 > due to no asciidoc or xmlto packages installed here. > Dave Thanks for report Dave! Crap, I thought man pages generation were resolved already. As to compiler on OW, Peter, do we have a chance to narrow down what exactly is broken there? |
|
From: Ed B. <be...@mi...> - 2013-12-10 11:56:42
|
"H. Peter Anvin" wrote: > >You realize that MSVC still doesn't support most C99 feature, right? Scary but true. Another project that I'm involved with (Wireshark) has converted the entire codebase to be compilable with the C++ compiler. Microsoft's C++ compiler is much more actively developed. Note that this did NOT involve rewriting everything to use objects and classes, but simply to convert the code so that it was legal C++ as well as legal C. My understanding is that the gcc project did this too, and for similar reasons. Ed |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 18:37:17
|
On 12/10/2013 03:56 AM, Ed Beroset wrote: > "H. Peter Anvin" wrote: >> >> You realize that MSVC still doesn't support most C99 feature, right? Scary but true. > > Another project that I'm involved with (Wireshark) has converted the entire codebase to be compilable with the C++ compiler. Microsoft's C++ compiler is much more actively developed. Note that this did NOT involve rewriting everything to use objects and classes, but simply to convert the code so that it was legal C++ as well as legal C. My understanding is that the gcc project did this too, and for similar reasons. > > Ed > Hey Ed, long time no see! Yes, it would be good if we could compile with a C++ compiler. It shouldn't be all that hard to do, but I think I tried it at one point and it will need some help. -hpa |
|
From: Ed B. <be...@mi...> - 2013-12-13 20:41:12
|
H. Peter Anvin wrote: > On 12/10/2013 03:56 AM, Ed Beroset wrote: >> "H. Peter Anvin" wrote: >>> >>> You realize that MSVC still doesn't support most C99 feature, right? Scary but true. >> >> Another project that I'm involved with (Wireshark) has converted the entire codebase to be compilable with the C++ compiler. Microsoft's C++ compiler is much more actively developed. Note that this did NOT involve rewriting everything to use objects and classes, but simply to convert the code so that it was legal C++ as well as legal C. My understanding is that the gcc project did this too, and for similar reasons. >> >> Ed >> > > Hey Ed, long time no see! Yep. I've been waaay too busy. > Yes, it would be good if we could compile with a C++ compiler. It > shouldn't be all that hard to do, but I think I tried it at one point > and it will need some help. It's not trivial, but it's more tedious than difficult and often results in better code anyway. We used gcc with the -Wc++-compat option to help identify the problem areas. When I did that with the wireshark project, I found the following: type count percent implicit_casts 4013 81.58% keyword_use 634 12.89% enum_conversion 197 4.00% uninit_const 7 0.14% field_typedef 5 0.10% special_operator 3 0.06% incompat_ptr 2 0.04% other 58 1.18% Because the vast majority of these (over 98%) were of only three different kinds which are mostly trivial fixes, it didn't take that long to plow through the entire project. I haven't done this (and don't realistically have the time for it) on the NASM project, but I would strongly suspect a similar pattern. Ed |
|
From: H. P. A. <hp...@zy...> - 2013-12-13 22:17:39
|
On 12/13/2013 12:40 PM, Ed Beroset wrote: > >> Yes, it would be good if we could compile with a C++ compiler. It >> shouldn't be all that hard to do, but I think I tried it at one point >> and it will need some help. > > It's not trivial, but it's more tedious than difficult and often results > in better code anyway. We used gcc with the -Wc++-compat option to help > identify the problem areas. When I did that with the wireshark project, > I found the following: > > type count percent > implicit_casts 4013 81.58% > keyword_use 634 12.89% > enum_conversion 197 4.00% > uninit_const 7 0.14% > field_typedef 5 0.10% > special_operator 3 0.06% > incompat_ptr 2 0.04% > other 58 1.18% > > Because the vast majority of these (over 98%) were of only three > different kinds which are mostly trivial fixes, it didn't take that long > to plow through the entire project. I haven't done this (and don't > realistically have the time for it) on the NASM project, but I would > strongly suspect a similar pattern. > Enum conversion and void casts dominate in NASM. This is unfortunately rather painful to work through. -hpa |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 16:31:19
|
Are you building from git or tarball? Cyrill Gorcunov <gor...@gm...> wrote: >On Mon, Dec 09, 2013 at 11:44:36PM -0800, Dave Yeo wrote: >> On 12/09/13 10:38 pm, H. Peter Anvin wrote: >> > Similarly, OpenWatcom only supports a subset of C99 features... >although we no longer build OS/2 binaries as part of the standard >build... ;) >> >> I build on OS/2 with configure and make using GCC 4.4.6 now as the OW > >> built binaries are subtly broken (fail 4 out of a couple of hundred >H264 >> conformance tests). >> BTW, the build (2.11rc4) currently dies here after linking nasm.exe >and >> ndisasm.exe with >> false -b docbook -d manpage -o nasm.xml nasm.txt >> make: *** [nasm.xml] Error 1 >> due to no asciidoc or xmlto packages installed here. >> Dave > >Thanks for report Dave! Crap, I thought man pages generation were >resolved already. >As to compiler on OW, Peter, do we have a chance to narrow down what >exactly is >broken there? -- Sent from my mobile phone. Please pardon brevity and lack of formatting. |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 19:02:17
|
On 12/09/2013 11:54 PM, Cyrill Gorcunov wrote: > On Mon, Dec 09, 2013 at 11:44:36PM -0800, Dave Yeo wrote: >> On 12/09/13 10:38 pm, H. Peter Anvin wrote: >>> Similarly, OpenWatcom only supports a subset of C99 features... although we no longer build OS/2 binaries as part of the standard build... ;) >> >> I build on OS/2 with configure and make using GCC 4.4.6 now as the OW >> built binaries are subtly broken (fail 4 out of a couple of hundred H264 >> conformance tests). >> BTW, the build (2.11rc4) currently dies here after linking nasm.exe and >> ndisasm.exe with >> false -b docbook -d manpage -o nasm.xml nasm.txt >> make: *** [nasm.xml] Error 1 >> due to no asciidoc or xmlto packages installed here. >> Dave > > Thanks for report Dave! Crap, I thought man pages generation were resolved already. > As to compiler on OW, Peter, do we have a chance to narrow down what exactly is > broken there? > At least one is a blatant OW bug: if (n <= 0xFFFFFFFF) ... where n is a uint64_t, and OW claims it is always true. -hpa |
|
From: Cyrill G. <gor...@gm...> - 2013-12-10 19:13:16
|
On Tue, Dec 10, 2013 at 11:02:00AM -0800, H. Peter Anvin wrote: > > > > Thanks for report Dave! Crap, I thought man pages generation were resolved already. > > As to compiler on OW, Peter, do we have a chance to narrow down what exactly is > > broken there? > > > > At least one is a blatant OW bug: > > if (n <= 0xFFFFFFFF) > > ... where n is a uint64_t, and OW claims it is always true. yes, I saw, and that's wondering me -- I mean I don't get why it is so. |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 19:21:47
|
On 12/10/2013 11:13 AM, Cyrill Gorcunov wrote: > On Tue, Dec 10, 2013 at 11:02:00AM -0800, H. Peter Anvin wrote: >>> >>> Thanks for report Dave! Crap, I thought man pages generation were resolved already. >>> As to compiler on OW, Peter, do we have a chance to narrow down what exactly is >>> broken there? >>> >> >> At least one is a blatant OW bug: >> >> if (n <= 0xFFFFFFFF) >> >> ... where n is a uint64_t, and OW claims it is always true. > > yes, I saw, and that's wondering me -- I mean I don't get why it is so. > I think OpenWatcom's handling of 64-bit numbers is just broken. It was introduced when interest in OW was already waning. -hpa |
|
From: Dave Y. <dav...@gm...> - 2013-12-10 20:58:40
|
On 12/10/13 11:21 am, H. Peter Anvin wrote: > On 12/10/2013 11:13 AM, Cyrill Gorcunov wrote: >> On Tue, Dec 10, 2013 at 11:02:00AM -0800, H. Peter Anvin wrote: >>>> >>>> Thanks for report Dave! Crap, I thought man pages generation were resolved already. >>>> As to compiler on OW, Peter, do we have a chance to narrow down what exactly is >>>> broken there? >>>> >>> >>> At least one is a blatant OW bug: >>> >>> if (n<= 0xFFFFFFFF) >>> >>> ... where n is a uint64_t, and OW claims it is always true. >> >> yes, I saw, and that's wondering me -- I mean I don't get why it is so. >> > > I think OpenWatcom's handling of 64-bit numbers is just broken. It was > introduced when interest in OW was already waning. > There's a good chance that the ver 2 fork has fixed these issues as it is supposed to be introducing support for 64bit binaries. I'll try downloading it later (I'm on dial-up so 100 MB downloads are slow). See http://sourceforge.net/projects/openwatcom/ and https://github.com/open-watcom Dave |
|
From: Cyrill G. <gor...@gm...> - 2013-12-10 06:13:54
|
On Mon, Dec 09, 2013 at 09:55:10PM -0800, H. Peter Anvin wrote: > On 12/07/2013 10:12 AM, nasm-bot for Cyrill Gorcunov wrote: > > Commit-ID: 71f71c0dbe204d8d6a58e695c038bf0508d3b406 > > Gitweb: http://repo.or.cz/w/nasm.git?a=commitdiff;h=71f71c0dbe204d8d6a58e695c038bf0508d3b406 > > Author: Cyrill Gorcunov <gor...@gm...> > > AuthorDate: Sat, 7 Dec 2013 16:12:07 +0400 > > Committer: Cyrill Gorcunov <gor...@gm...> > > CommitDate: Sat, 7 Dec 2013 16:12:07 +0400 > > > > iflag: Introduce IFLAG_INIT helper > > > > No, this once again introduces an unnecessary C99ism, which we really > are trying to avoid. Wait, Peter, don't we require the compiler to support C99? |
|
From: Cyrill G. <gor...@gm...> - 2013-12-10 19:55:49
|
On Tue, Dec 10, 2013 at 11:21:32AM -0800, H. Peter Anvin wrote: > On 12/10/2013 11:13 AM, Cyrill Gorcunov wrote: > > On Tue, Dec 10, 2013 at 11:02:00AM -0800, H. Peter Anvin wrote: > >>> > >>> Thanks for report Dave! Crap, I thought man pages generation were resolved already. > >>> As to compiler on OW, Peter, do we have a chance to narrow down what exactly is > >>> broken there? > >>> > >> > >> At least one is a blatant OW bug: > >> > >> if (n <= 0xFFFFFFFF) > >> > >> ... where n is a uint64_t, and OW claims it is always true. > > > > yes, I saw, and that's wondering me -- I mean I don't get why it is so. > > > > I think OpenWatcom's handling of 64-bit numbers is just broken. It was > introduced when interest in OW was already waning. Then I suppose there is nothing much we can do, we rely on correct u64 support heavily. |
|
From: H. P. A. <hp...@zy...> - 2013-12-10 20:21:05
|
On 12/10/2013 11:55 AM, Cyrill Gorcunov wrote: >> >> I think OpenWatcom's handling of 64-bit numbers is just broken. It was >> introduced when interest in OW was already waning. > > Then I suppose there is nothing much we can do, we rely on correct u64 > support heavily. > Pretty much. Sad. However, the only platform OW runs on which we don't have a working gcc cross-compiler for is OS/2. -hpa |
|
From: Dave Y. <dav...@gm...> - 2013-12-10 17:41:31
|
On 12/10/13 08:30 am, H. Peter Anvin wrote:
> Are you building from git or tarball?
I was building from tarball. Testing git head the compile ends with
f:/usr/bin/sh.exe: ASCIIDOC@: No such file or directory
make: *** [nasm.xml] Error 1
I hadn't tried using OW (1.9) for a while. Compiling from tarball is now
broken (and git head fails due to Error(F41): No DEFAULT commands for
making (insns.pl))
wcl386 -c -zq -6 -ox -wx -ze -fpi -bt=OS2 -I"I:\WATCOM/h"
-I"I:\WATCOM/h/os2" -I. -I. -DHAVE_CONFIG_H -fo=parser.obj parser.c
parser.c(224): Error! E1078: Invalid type for switch expression
parser.c(1034): Warning! W124: Comparison result always 1
parser.c(1036): Warning! W124: Comparison result always 1
parser.c(1047): Error! E1078: Invalid type for switch expression
Error: Compiler returned a bad status compiling "parser.c"
Error(E42): Last command making (parser.obj;os2) returned a bad status
Error(E02): Make execution terminated
Dave
>
> Cyrill Gorcunov<gor...@gm...> wrote:
>> On Mon, Dec 09, 2013 at 11:44:36PM -0800, Dave Yeo wrote:
>>> On 12/09/13 10:38 pm, H. Peter Anvin wrote:
>>>> Similarly, OpenWatcom only supports a subset of C99 features...
>> although we no longer build OS/2 binaries as part of the standard
>> build... ;)
>>>
>>> I build on OS/2 with configure and make using GCC 4.4.6 now as the OW
>>
>>> built binaries are subtly broken (fail 4 out of a couple of hundred
>> H264
>>> conformance tests).
>>> BTW, the build (2.11rc4) currently dies here after linking nasm.exe
>> and
>>> ndisasm.exe with
>>> false -b docbook -d manpage -o nasm.xml nasm.txt
>>> make: *** [nasm.xml] Error 1
>>> due to no asciidoc or xmlto packages installed here.
>>> Dave
>>
>> Thanks for report Dave! Crap, I thought man pages generation were
>> resolved already.
>> As to compiler on OW, Peter, do we have a chance to narrow down what
>> exactly is
>> broken there?
>
|
|
From: H. P. A. <hp...@zy...> - 2013-12-10 18:35:57
|
On 12/10/2013 09:41 AM, Dave Yeo wrote: > On 12/10/13 08:30 am, H. Peter Anvin wrote: >> Are you building from git or tarball? > > I was building from tarball. Testing git head the compile ends with > f:/usr/bin/sh.exe: ASCIIDOC@: No such file or directory > make: *** [nasm.xml] Error 1 OK, will look at it. > I hadn't tried using OW (1.9) for a while. Compiling from tarball is now > broken (and git head fails due to Error(F41): No DEFAULT commands for > making (insns.pl)) > wcl386 -c -zq -6 -ox -wx -ze -fpi -bt=OS2 -I"I:\WATCOM/h" > -I"I:\WATCOM/h/os2" -I. -I. -DHAVE_CONFIG_H -fo=parser.obj parser.c > parser.c(224): Error! E1078: Invalid type for switch expression > parser.c(1034): Warning! W124: Comparison result always 1 > parser.c(1036): Warning! W124: Comparison result always 1 > parser.c(1047): Error! E1078: Invalid type for switch expression > Error: Compiler returned a bad status compiling "parser.c" > Error(E42): Last command making (parser.obj;os2) returned a bad status > Error(E02): Make execution terminated > Yes, I think OpenWatcom is beyond help, sadly. You said you were building using gcc; is that an environment that can be ported to a Linux host? I tried at one point cross-compiling a gcc for OS/2 on Linux, but there were some OS/2-isms in some of the patched files that made it not work. -hpa |
|
From: Dave Y. <dav...@gm...> - 2013-12-10 20:53:53
|
On 12/10/13 10:35 am, H. Peter Anvin wrote: > On 12/10/2013 09:41 AM, Dave Yeo wrote: >> On 12/10/13 08:30 am, H. Peter Anvin wrote: >>> Are you building from git or tarball? >> >> I was building from tarball. Testing git head the compile ends with >> f:/usr/bin/sh.exe: ASCIIDOC@: No such file or directory >> make: *** [nasm.xml] Error 1 > > OK, will look at it. Thanks > >> I hadn't tried using OW (1.9) for a while. Compiling from tarball is now >> broken (and git head fails due to Error(F41): No DEFAULT commands for >> making (insns.pl)) >> wcl386 -c -zq -6 -ox -wx -ze -fpi -bt=OS2 -I"I:\WATCOM/h" >> -I"I:\WATCOM/h/os2" -I. -I. -DHAVE_CONFIG_H -fo=parser.obj parser.c >> parser.c(224): Error! E1078: Invalid type for switch expression >> parser.c(1034): Warning! W124: Comparison result always 1 >> parser.c(1036): Warning! W124: Comparison result always 1 >> parser.c(1047): Error! E1078: Invalid type for switch expression >> Error: Compiler returned a bad status compiling "parser.c" >> Error(E42): Last command making (parser.obj;os2) returned a bad status >> Error(E02): Make execution terminated >> > > Yes, I think OpenWatcom is beyond help, sadly. You said you were > building using gcc; is that an environment that can be ported to a Linux > host? I tried at one point cross-compiling a gcc for OS/2 on Linux, but > there were some OS/2-isms in some of the patched files that made it not > work. > I don't know of anyone who has ported the environment to Linux though in theory it should be possible. Dave |
|
From: anonymous c. <nas...@us...> - 2013-12-11 15:38:17
|
+1 for C89 + (u)int64 = lowest common denominator -- it's the only path that has worked well for me for many different platforms/compilers and more than a decade. As for Watcom C, last I checked case statements did not support 64-bit integer types. I did file a bug for that but can't look it up -- their (bug) site is down right now. |
|
From: H. P. A. <hp...@zy...> - 2013-12-11 22:38:44
|
On 12/11/2013 07:38 AM, anonymous coward wrote: > +1 for C89 + (u)int64 = lowest common denominator -- > it's the only path that has worked well for me for many > different platforms/compilers and more than a decade. > > As for Watcom C, last I checked case statements did > not support 64-bit integer types. I did file a bug for that > but can't look it up -- their (bug) site is down right now. > Yes, they don't support 64-bit numbers in switch statements, but there seem to be more problems than that. -hpa |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X