nasm-devel — NASM development work

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Ed B. <be...@mi...>]

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

Re: [Nasm-devel] [nasm:master] mib: Handle MIB EA in a different way from regular EA's

[H. P. A. <hp...@zy...>]

On 12/11/2013 05:03 PM, nasm-bot for Jin Kyu Song wrote:
> 
> NOSPLIT specifier does not have an effect in mib, so [nosplit eax + eax*1]
> will be encoded as [eax, eax] rather than [eax*2] as in a regular EA.
> 

I'm wondering if we shouldn't make NOSPLIT because exactly like this; I
would think [nosplit eax + eax*1] should generate a base eax and index
eax*1.  Anyone who would disagree with that opinion?

	-hpa

Re: [Nasm-devel] [nasm:master] mib: Handle MIB EA in a different way from regular EA's

[anonymous c. <nas...@us...>]

>> mib: Handle MIB EA in a different way from regular EA's
>
> BNDMK needs that restriction too -- so... MIB in insns.dat?
>
> Also, the BNDLDX and BNDSTX entries seem asymmetric.

In addition, re-consider those explicit mem op sizes on
all of the BND* instructions. They seem to fall into three
different groups:

1) pointers to structures -- BNDMOV rB,M and M,rB
2) pointers to locations -- BNDC[LUN] rB,M
3) special SIB handling -- BND{LD,ST}X and BNDMK

The first group is similar to...

- L[EDSFG]S Gv,Mp (w:v)
- [LS][GI]DT Mp (w:y)
- BOUND Gv,Ma
- F(N)LDENV M14/M28 and FSTENV M14/M28
- F(N)SAVE M14/M28 and FRSTOR M94/M108
- FXSAVE M512 and FXRSTOR M512
- XSAVE M, XSAVEOPT M, and XRSTOR M

...none of which support explicit sizes -- so BNDMOV
should follow that precedence, rather than be SQ/SO.

The second group is similar to...

- LEA Gv,M
- INVLPG M
- PREFETCH* M
- VPREFETCH* M (K1OM)
- CLEVICT* M (K1OM)
- CLFLUSH M
- NOP M

...none of which support explicit sizes -- so BNDC[LUN]
should follow that precedence, rather than be SD/SQ.

(For convenience, an explicit byte size qualifier would be
okay for the first and second group.)

The third group is new altogether -- it doesn't permit any
EA transformations (*3/5/9, b->i, b<->i). In addition, rIP-
relative causes #UD. And for BNDMK, scale=2/4/8 does
get ignored (which should warn). But once again, there's
no real size of mem op here -- so also drop it for these.

Re: [Nasm-devel] [nasm:master] mib: Handle MIB EA in a different way from regular EA's

[anonymous c. <nas...@us...>]

> mib: Handle MIB EA in a different way from regular EA's

BNDMK needs that restriction too -- so... MIB in insns.dat?

Also, the BNDLDX and BNDSTX entries seem asymmetric.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[anonymous c. <nas...@us...>]

+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.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Dave Y. <dav...@gm...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Dave Y. <dav...@gm...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Cyrill G. <gor...@gm...>]

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.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Cyrill G. <gor...@gm...>]

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.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Dave Y. <dav...@gm...>]

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?
>

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Ed B. <be...@mi...>]

"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

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Cyrill G. <gor...@gm...>]

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?

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Dave Y. <dav...@gm...>]

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?
>

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Cyrill G. <gor...@gm...>]

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.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[H. P. A. <hp...@zy...>]

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.

Re: [Nasm-devel] [nasm:master] iflag: Introduce IFLAG_INIT helper

[Cyrill G. <gor...@gm...>]

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?