nasm-devel — NASM development work

[Nasm-devel] The NASM build robot is back...

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

I have brought the NASM build robot back online.  I dropped the os2
build, though... it was just way too painful to keep alive.

	-hpa

Re: [Nasm-devel] adding AVX2 transactional synchronization extensions

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

On 02/14/2012 02:03 PM, Cyrill Gorcunov wrote:
> Hi, while disasm is not yet done, here what I thought about
> assembler part. It's not yet complete but just to share.
>
> At moment the idea is to try to guess if we need to emit
> additional lock prefix for xacquire/release instructions.
>
> (the patch for insns.dat
>
> +;
> +; transactional synchronization extensions
> +XABORT		imm8				[i:	c6 f8 ib] FUTURE,HLE
> +XBEGIN		imm16				[i:	c7 f8 iw] FUTURE,HLE
> +XBEGIN		imm32				[i:	c7 f8 id] FUTURE,HLE
> +XEND		void				[	0f 01 d5] FUTURE,HLE
> +XTEST		void				[	0f 01 d6] FUTURE,HLE,RTM
> +
>
> is in my tree already, simply desided to not push it upstream
> until everything is done).
>

I pushed that one (with fixes) already.

>
> +static bool hle_should_emit_lock(const struct itemplate *t, int prefix)
> +{
> +    switch ((int)t->opcode) {
> +    case I_ADD:
> +    case I_ADC:
> +    case I_AND:
> +    case I_BTC:
> +    case I_BTR:
> +    case I_BTS:
> +    case I_CMPXCHG:
> +    case I_CMPXCHG8B:
> +    case I_DEC:
> +    case I_INC:
> +    case I_NEG:
> +    case I_NOT:
> +    case I_OR:
> +    case I_SBB:
> +    case I_SUB:
> +    case I_XOR:
> +    case I_XADD:
> +        return true;
> +    case I_MOV: /* FIXME: Not all MOV requires lock on xrelease */
> +        return true;
> +    case I_XCHG:
> +        return false;
> +    }
> +
> +    return false;
> +}
> +

I would strongly suggest that this should be data-driven; either a byte 
code or a flag.

IIRC MOV never requires LOCK, nor does it accept it.

	-hpa

Re: [Nasm-devel] adding AVX2 transactional synchronization extensions

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

On 02/14/2012 02:24 PM, Cyrill Gorcunov wrote:
>>
>> IIRC MOV never requires LOCK, nor does it accept it.
>>
>
> quoting spec:
> The XRELEASE prefix hint can only be used with the following instructions:
>
>   - The "MOV mem, reg" (Opcode 88H/89H) and "MOV mem, imm" (Opcode C6H/C7H) instructions.
>     In these cases, the XRELEASE is recognized without the presence of the LOCK
>     prefix.
>
> So I seem to miss something obvious?
>

Not really... it's what it says up there... doesn't require a LOCK 
prefix.  Note that only some form of MOV is supported, which is another 
reason this needs to be part of the instruction pattern in insns.dat.

	-hpa

Re: [Nasm-devel] adding AVX2 transactional synchronization extensions

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

On Tue, Feb 14, 2012 at 02:27:52PM -0800, H. Peter Anvin wrote:
> On 02/14/2012 02:24 PM, Cyrill Gorcunov wrote:
> >>
> >>IIRC MOV never requires LOCK, nor does it accept it.
> >>
> >
> >quoting spec:
> >The XRELEASE prefix hint can only be used with the following instructions:
> >
> >  - The "MOV mem, reg" (Opcode 88H/89H) and "MOV mem, imm" (Opcode C6H/C7H) instructions.
> >    In these cases, the XRELEASE is recognized without the presence of the LOCK
> >    prefix.
> >
> >So I seem to miss something obvious?
> >
> 
> Not really... it's what it says up there... doesn't require a LOCK
> prefix.  Note that only some form of MOV is supported, which is
> another reason this needs to be part of the instruction pattern in
> insns.dat.
> 

OK, I seem to understand. Will post patch once it get done (in a couple
of days I hope).

	Cyrill

Re: [Nasm-devel] adding AVX2 transactional synchronization extensions

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

On Tue, Feb 14, 2012 at 02:17:22PM -0800, H. Peter Anvin wrote:
> On 02/14/2012 02:03 PM, Cyrill Gorcunov wrote:
> >Hi, while disasm is not yet done, here what I thought about
> >assembler part. It's not yet complete but just to share.
> >
> >At moment the idea is to try to guess if we need to emit
> >additional lock prefix for xacquire/release instructions.
> >
> >(the patch for insns.dat
> >
> >+;
> >+; transactional synchronization extensions
> >+XABORT		imm8				[i:	c6 f8 ib] FUTURE,HLE
> >+XBEGIN		imm16				[i:	c7 f8 iw] FUTURE,HLE
> >+XBEGIN		imm32				[i:	c7 f8 id] FUTURE,HLE
> >+XEND		void				[	0f 01 d5] FUTURE,HLE
> >+XTEST		void				[	0f 01 d6] FUTURE,HLE,RTM
> >+
> >
> >is in my tree already, simply desided to not push it upstream
> >until everything is done).
> >
> 
> I pushed that one (with fixes) already.
> 

Ah, I forgot to update repo ;)

> I would strongly suggest that this should be data-driven; either a
> byte code or a flag.

ok, i'll think about it, thanks!

> 
> IIRC MOV never requires LOCK, nor does it accept it.
> 

quoting spec:
The XRELEASE prefix hint can only be used with the following instructions:

 - The "MOV mem, reg" (Opcode 88H/89H) and "MOV mem, imm" (Opcode C6H/C7H) instructions.
   In these cases, the XRELEASE is recognized without the presence of the LOCK
   prefix.

So I seem to miss something obvious?

	Cyrill

[Nasm-devel] adding AVX2 transactional synchronization extensions

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

Hi, while disasm is not yet done, here what I thought about
assembler part. It's not yet complete but just to share.

At moment the idea is to try to guess if we need to emit
additional lock prefix for xacquire/release instructions.

(the patch for insns.dat

+;
+; transactional synchronization extensions
+XABORT		imm8				[i:	c6 f8 ib] FUTURE,HLE
+XBEGIN		imm16				[i:	c7 f8 iw] FUTURE,HLE
+XBEGIN		imm32				[i:	c7 f8 id] FUTURE,HLE
+XEND		void				[	0f 01 d5] FUTURE,HLE
+XTEST		void				[	0f 01 d6] FUTURE,HLE,RTM
+

is in my tree already, simply desided to not push it upstream
until everything is done).

Commens, ideas?

	Cyrill
---
diff --git a/assemble.c b/assemble.c
index f1583fd..0734481 100644
--- a/assemble.c
+++ b/assemble.c
@@ -340,6 +340,36 @@ static bool jmp_match(int32_t segment, int64_t offset, int bits,
     return (isize >= -128 && isize <= 127); /* is it byte size? */
 }
 
+static bool hle_should_emit_lock(const struct itemplate *t, int prefix)
+{
+    switch ((int)t->opcode) {
+    case I_ADD:
+    case I_ADC:
+    case I_AND:
+    case I_BTC:
+    case I_BTR:
+    case I_BTS:
+    case I_CMPXCHG:
+    case I_CMPXCHG8B:
+    case I_DEC:
+    case I_INC:
+    case I_NEG:
+    case I_NOT:
+    case I_OR:
+    case I_SBB:
+    case I_SUB:
+    case I_XOR:
+    case I_XADD:
+        return true;
+    case I_MOV: /* FIXME: Not all MOV requires lock on xrelease */
+        return true;
+    case I_XCHG:
+        return false;
+    }
+
+    return false;
+}
+
 int64_t assemble(int32_t segment, int64_t offset, int bits, uint32_t cp,
                  insn * instruction, struct ofmt *output, efunc error,
                  ListGen * listgen)
@@ -497,7 +527,8 @@ int64_t assemble(int32_t segment, int64_t offset, int bits, uint32_t cp,
         else
             while (itimes--) {
                 for (j = 0; j < MAXPREFIX; j++) {
-                    uint8_t c = 0;
+                    uint16_t c = 0;
+                    int bytes = 1;
                     switch (instruction->prefixes[j]) {
                     case P_WAIT:
                         c = 0x9B;
@@ -514,6 +545,20 @@ int64_t assemble(int32_t segment, int64_t offset, int bits, uint32_t cp,
                     case P_REP:
                         c = 0xF3;
                         break;
+                    case P_XACQUIRE:
+                        if (hle_should_emit_lock(&temp, P_XACQUIRE)) {
+                            c = (0xF0 << 8) | 0xF2;
+                            bytes = 2;
+                        } else
+                            c = 0xF2;
+                        break;
+                    case P_XRELEASE:
+                        if (hle_should_emit_lock(&temp, P_XRELEASE)) {
+                            c = (0xF0 << 8) | 0xF3;
+                            bytes = 2;
+                        } else
+                            c = 0xF3;
+                        break;
                     case R_CS:
                         if (bits == 64) {
                             error(ERR_WARNING | ERR_PASS2,
@@ -594,9 +639,8 @@ int64_t assemble(int32_t segment, int64_t offset, int bits, uint32_t cp,
                     default:
                         error(ERR_PANIC, "invalid instruction prefix");
                     }
-                    if (c != 0) {
-                        out(offset, segment, &c, OUT_RAWDATA, 1,
-                            NO_SEG, NO_SEG);
+                    if (c) {
+                        out(offset, segment, &c, OUT_RAWDATA, bytes, NO_SEG, NO_SEG);
                         offset++;
                     }
                 }
diff --git a/nasm.h b/nasm.h
index 1569667..23d7e4b 100644
--- a/nasm.h
+++ b/nasm.h
@@ -486,6 +486,8 @@ enum prefixes { /* instruction prefixes */
     P_REPZ,
     P_TIMES,
     P_WAIT,
+    P_XACQUIRE,
+    P_XRELEASE,
     PREFIX_ENUM_LIMIT
 };
 
@@ -562,6 +564,7 @@ enum ea_type {
 enum prefix_pos {
     PPS_WAIT,   /* WAIT (technically not a prefix!) */
     PPS_LREP,   /* Lock or REP prefix */
+    PPS_HLE,    /* xacquire/xrelease (hardware lock elision prefix) */
     PPS_SEG,    /* Segment override prefix */
     PPS_OSIZE,  /* Operand size prefix */
     PPS_ASIZE,  /* Address size prefix */
diff --git a/parser.c b/parser.c
index 37d7138..825da0d 100644
--- a/parser.c
+++ b/parser.c
@@ -80,6 +80,9 @@ static int prefix_slot(int prefix)
     case R_FS:
     case R_GS:
         return PPS_SEG;
+    case P_XACQUIRE:
+    case P_XRELEASE:
+        return PPS_HLE;
     case P_LOCK:
     case P_REP:
     case P_REPE:
diff --git a/tokens.dat b/tokens.dat
index c7d3b97..eff15f6 100644
--- a/tokens.dat
+++ b/tokens.dat
@@ -52,6 +52,8 @@ repnz
 repz
 times
 wait
+xacquire
+xrelease
 
 % TOKEN_SPECIAL, 0, S_*
 abs

Re: [Nasm-devel] [PATCH] Don't forget to setup warning levels on preprocessor phase

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

On Mon, Dec 05, 2011 at 02:03:26AM +0400, Cyrill Gorcunov wrote:
> I'm not sure if NOT passing warning levels to preprocessor
> level was done intentionally, so before commit patch out I
> would like to hear opinions.
> 
> 	Cyrill
> ---
> From b574b074a727e92d439a47c1a5d790bc588d001c Mon Sep 17 00:00:00 2001
> From: Cyrill Gorcunov <gor...@gm...>
> Date: Mon, 5 Dec 2011 01:56:40 +0400
> Subject: [PATCH] Don't forget to setup warning levels on preprocessor phase
> 
> http://bugzilla.nasm.us/show_bug.cgi?id=3143109
> 
> Signed-off-by: Cyrill Gorcunov <gor...@gm...>
> ---

Sigh, I pushed it out (occasionally). So please, if anyone have objections,
don't hesitate to complain! 

	Cyrill

[Nasm-devel] [PATCH] Don't forget to setup warning levels on preprocessor phase

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

I'm not sure if NOT passing warning levels to preprocessor
level was done intentionally, so before commit patch out I
would like to hear opinions.

	Cyrill
---
>From b574b074a727e92d439a47c1a5d790bc588d001c Mon Sep 17 00:00:00 2001
From: Cyrill Gorcunov <gor...@gm...>
Date: Mon, 5 Dec 2011 01:56:40 +0400
Subject: [PATCH] Don't forget to setup warning levels on preprocessor phase

http://bugzilla.nasm.us/show_bug.cgi?id=3143109

Signed-off-by: Cyrill Gorcunov <gor...@gm...>
---
 nasm.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/nasm.c b/nasm.c
index 7d38d60..c6ddc73 100644
--- a/nasm.c
+++ b/nasm.c
@@ -408,8 +408,9 @@ int main(int argc, char **argv)
 
             location.known = false;
 
-	    /* pass = 1; */
+            /* pass = 1; */
             preproc->reset(inname, 3, &nasmlist, depend_ptr);
+            memcpy(warning_on, warning_on_global, (ERR_WARN_MAX+1) * sizeof(bool));
 
             while ((line = preproc->getline())) {
                 /*
-- 
1.7.7.3

[Nasm-devel] [Slightly OT contract work] Yasm++ projects

[C. B. <cbe...@pa...>]

Hi all

PathScale has been sponsoring work on Yasm++ and we need an extra hand.  
Please contact me off list if you don't mind C++ code and you're 
interested in any of the following projects

1) Tight integration of NASM parser with yasm++ (We're using sticky tape 
currently)
2) Improvements targeting advanced users (I have feedback from some 
members of the libav community)
3) Tight integration with our nextgen code generator (something along 
the lines of MC if you're familiar with LLVM)
4) Instrumentation support (drop-in replace gas so we can inject calls 
around functions, loops, for, switch.. etc - This project would require 
more offline discussion)

Most of the work above will probably go all open source.  I'm happy to 
keep anyone updated on progress who is interested.

Best,

Christopher

#pathscale - irc.freenode.net

Re: [Nasm-devel] NASM 2.09.10 manual ("Introduction") -- slight update needed

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

On Sat, Nov 26, 2011 at 07:57:38AM -0500, Frank Kotler wrote:
> Rugxulo wrote:
> > Hi,
> 
> Hi Rugxulo,
> 
> Sorry for the delay in getting back to you. (and Thanks for your work on 
> FreeDos!!!)
> 

Hi Frank, Rugxulo,

so will you provide a patch to apply? ;)

	Cyrill

Re: [Nasm-devel] NASM 2.09.10 manual ("Introduction") -- slight update needed

[Frank K. <fbk...@my...>]

Rugxulo wrote:
> Hi,

Hi Rugxulo,

Sorry for the delay in getting back to you. (and Thanks for your work on 
FreeDos!!!)

>    Not sure if this is the right email (or right person or place ...

It'll do. I'll pass your concerns on to the developer's list (Hi list), 
but the relevant section of the manual is "historical" (perhaps this 
isn't made clear enough). It is Simon's rationale for writing Nasm in 
the first place. If taken as "Why should I choose Nasm *now*?", it would 
be quite out of date, as you point out!

Thanks for the feedback!

Best,
Frank

> or if even worth mentioning!!), but here's a small revision of the
> latest NASM manual. Apparently it still says some (slightly outdated)
> info. (Feel free to ignore this, I'm just rambling for completeness,
> to get it off my chest, so to speak.)
> 
> "
> a86 is good, but not free, and in particular you don't get any 32-bit
> capability until you pay. It's DOS only, too.
> "
> 
> **** DOS-hosted only, but optional OMF output means you could target
> other OSes, e.g. his AWIN package for Win95. Granted, it's not as
> convenient, but it sorta works.
> 
> "
> gas is free, and ports over to DOS and Unix, but it's not very good,
> since it's designed to be a back end to gcc, which always feeds it
> correct code. So its error checking is minimal. Also, its syntax is
> horrible, from the point of view of anyone trying to actually write
> anything in it. Plus you can't write 16-bit code in it (properly.)
> "
> 
> **** It can (more or less) write proper 16-bit code now, but it's
> kinda buggy (esp. 2.21 !!), esp. if you try to do anything like
> outputting raw (flat) binaries, which needs weird LD or OBJCOPY hacks.
> (And some people, God help them, actually "like" AT&T, *shudder*!)
> 
> "
> as86 is specific to Minix and Linux, and (my version at least) doesn't
> seem to have much (or any) documentation.
> "
> 
> **** Weird (incompatible) a.out variant, but there is a (kinda old)
> Dev86DOS hosted build that works with (similarly old) BCC (circa
> 0.16.2, not latest 0.16.18). It can target DOS, and Dev86DOS does
> indeed have a DOS C library and outputs .COM.
> 
> "
> MASM isn't very good, and it's (was) expensive, and it runs only under DOS.
> "
> 
> **** Heavily debatable whether it's any good, some people LOVE it! But
> they swear by MASM 5 or 6.14 or similar. I forget what it's up to by
> now, at least 10.0 or such (with x64 support). But true, it's free
> (and has been, more or less, for ten years, in various forms, mostly
> seemingly?? "non-commercial only", e.g. latest MS VC Express).
> Allegedly 5 is from 1987 or such and ran natively on both OS/2 and DOS
> (and was first to support 386 output) while 6 was heavily improved
> ("ml.exe", rewritten? no more EXE2BIN needed) from 1992 or such and
> ran on DOS (through 6.11d) 386s (via PharLap) and later Win32. So
> clearly it's not (nor was for a long, long time) DOS-only (esp. since
> COFF was never used on DOS by MS or similar tools). P.S. MASM has had
> a kinda bizarre history, and I don't claim to really understand or
> know it fully (by far)!! EDIT:  Wikipedia says "Stable
> release	10.0.30319.1 / April 12, 2010; 18 months ago".
> 
> "
> TASM is better, but still strives for MASM compatibility, which means
> millions of directives and tons of red tape. And its syntax is
> essentially MASM's, with the contradictions and quirks that entails
> (although it sorts out some of those by means of Ideal mode.) It's
> expensive too. And it's DOS-only.
> "
> 
> **** I don't know when the DOS-only ceased to be true, but at least
> with TASM32 5.3 (circa 2000), it was Win32 only (or perhaps their
> weird 32RTM / DPMI32BI hybrid). For a brief while, it was freeware
> included in CodeGear's Turbo C++ Explorer 2006, but eventually that
> was phased out when Embarcadero took over. IIRC, it only supported MMX
> and maybe 686 stuff, nothing newer. I read later that they maybe
> finally updated it to 5.4, but I don't know what that entailed. But (I
> think??) it indeed was still outputting OMF/OBJ. I still have a copy
> (from above 2006), so I could check if needed.
> 
> 

Re: [Nasm-devel] on fix for BR3414012

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

On Sun, Oct 02, 2011 at 10:55:22AM -0700, H. Peter Anvin wrote:
...
> 
> What if we let %+ absorb surrounding TOK_WHITESPACE, so the above
> composites correctly?
> 
> 	-hpa
> 

Yeah, good idea, i'll check on the week.

	Cyrill

Re: [Nasm-devel] on fix for BR3414012

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

On 10/02/2011 05:10 AM, Cyrill Gorcunov wrote:
> 
> Btw, while were looking into this bug I found an interesting
> thing -- if some macro expands to nothing we don't return empy
> term but TOK_WHITESPACE instead. This is wrong. (For this reason
> x264 codec is not compilable with nasm.) This term should be
> a composite entity and has some additional info such as 'ok,
> this term is whitespace due to exponasion to empty line' and
> in case if there
> 
> 	TOK_ID %+ TOK_WHITESPACE_DUE_TO_EXPANSION %+ TOK_ID
> 
> we would drop TOK_WHITESPACE_DUE_TO_EXPANSION and simply join
> TOK_ID+TOK_ID.
> 
> Not sure how to make it in better way at moment though.
> 

What if we let %+ absorb surrounding TOK_WHITESPACE, so the above
composites correctly?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Nasm-devel] on fix for BR3414012

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

On Sun, Oct 02, 2011 at 08:20:17AM +0400, Cyrill Gorcunov wrote:
...
> 
> Yes, exactly. Thanks Keith!
> 

Btw, while were looking into this bug I found an interesting
thing -- if some macro expands to nothing we don't return empy
term but TOK_WHITESPACE instead. This is wrong. (For this reason
x264 codec is not compilable with nasm.) This term should be
a composite entity and has some additional info such as 'ok,
this term is whitespace due to exponasion to empty line' and
in case if there

	TOK_ID %+ TOK_WHITESPACE_DUE_TO_EXPANSION %+ TOK_ID

we would drop TOK_WHITESPACE_DUE_TO_EXPANSION and simply join
TOK_ID+TOK_ID.

Not sure how to make it in better way at moment though.

	Cyrill

Re: [Nasm-devel] on fix for BR3414012

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

On Sat, Oct 01, 2011 at 06:21:49PM -0500, Keith Kanios wrote:
> If I understand you correctly -- i.e.
> for(skip_white_(tline),tline,skip_white_(tline)) -- then that should
> be acceptable. %ifdef should never be allowed to be blank and thus
> should throw an error.
> 
> In short, yes, being consistent is more important than being concise.
> 
> Just my 2 ¢.
> 
> -Keith
> 

Yes, exactly. Thanks Keith!

	Cyrill

[Nasm-devel] on fix for BR3414012

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

Guys, I've just pushed out a fix for BR3414012 but note it
changes the preprocessor workflow a bit, in particular the
constructions like

 | %ifdef
 | %endif

are not longer valid (note the absence of variables names there).
I believe the same trailing space problem take a place for %ifenv
term (and bare %ifenv/%endif as well) but I didn't fixed it yet.

What do you think?

	Cyrill

[Nasm-devel] read and print with NASM

[adekoya a. <ade...@gm...>]

hi,

am new to nasm. I have installed it on my machine. i would love to adapt the
code below to read say two numbers from the console and then print the sum
of the numbers to the console.

i urgently need to learn nasm on windows so that I could use in my compiler.
I am developing a compiler for my msc project. the compiler would generate
NASM code . The NASM code would then b assembled and later be linked by
GCC.  So for now , I need to quickly work on my NASM knowlegdge. I would
appreciate your kind help.


;
----------------------------------------------------------------------------
; helloworld.asm
;
; This is a Win32 console program that writes "Hello, World" on one line and
; then exits.  It needs to be linked with a C library.
;
----------------------------------------------------------------------------

    global      _main
    extern      _printf
    extern      _scanf




    section .text
_main:
     push        message
     call        _printf

      add       esp, 4


    ret
message:
    db  'Hello World!', 10, 0

Re: [Nasm-devel] nasm devel active? what happened to the git repo?

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

On Sat, Sep 03, 2011 at 12:48:50AM -0500, Jorge Alberto Garcia wrote:
> Hi ! ,  i went to the site to see how is going with nasm development, i
> tried to get the last nasm version via git, it failed and i dont
> see any comment neither here nor on the site.
> 
> Can someone point me out how i can get access to the git repo ?
> 
> Thanks!

NASM repo should be accessible via normal way, ie

	git clone git://repo.or.cz/nasm.git

Sometime repo.or.cz fails (due to loads I believe)
but I see this pretty rare. So please retry.

And NASM development is still active as well.

	Cyrill

Re: [Nasm-devel] nasm devel active? what happened to the git repo?

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

> Hi ! ,  i went to the site to see how is going with nasm development, i
> tried to get the last nasm version via git, it failed and i dont
> see any comment neither here nor on the site.
> Can someone point me out how i can get access to the git repo ?

The usual

  git clone git://repo.or.cz/nasm.git nasm

seems to be working just fine for me as of writing this.

[Nasm-devel] nasm devel active? what happened to the git repo?

[Jorge A. G. <jor...@gm...>]

Hi ! ,  i went to the site to see how is going with nasm development, i
tried to get the last nasm version via git, it failed and i dont
see any comment neither here nor on the site.

Can someone point me out how i can get access to the git repo ?

Thanks!

Re: [Nasm-devel] Patch for "warning: case value ‘nn’ not in enumerated type ‘enum prefixes’"

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

On Wed, Aug 31, 2011 at 10:08:14AM +0200, Daniel Kozar wrote:
> Hello.
> Attached, please find a patch for the aforementioned warnings reported
> while compiling with gcc 4.5.1. It was made against today's master git
> revision, commit 9022212ba9c62c2404ce48b93158dd3fe58b68ba. This patch
> adds no new functionalities whatsoever.
> 
> D.K.

Hi Daniel,

first of all -- thanks! I'll review this patch as only
get spare time slot. Meanwhile, can I assume this patch
has your SOB? (see http://goo.gl/to5JV , "Signing your work").

	Cyrill

[Nasm-devel] Patch for "warning: case value ‘nn’ not in enumerated type ‘enum prefixes’"

[Daniel K. <los...@gm...>]

Hello.
Attached, please find a patch for the aforementioned warnings reported
while compiling with gcc 4.5.1. It was made against today's master git
revision, commit 9022212ba9c62c2404ce48b93158dd3fe58b68ba. This patch
adds no new functionalities whatsoever.

D.K.

Re: [Nasm-devel] avx2 gather ops fail

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

On Tue, Aug 23, 2011 at 11:01:07AM -0700, anonymous coward wrote:
> > Thanks a huge to nasm64developer for the testing file.
> > Are we allowed to pick it up into nasm test suite from
> > license POV?
> 
> The credit goes to H.J. Lu from Intel:
> 
>   http://sourceware.org/ml/binutils/2011-06/msg00150.html
> 
> I merely converted the gas code to NASM format -- so
> the original license should prevail.

OK, thanks!

	Cyrill

Re: [Nasm-devel] avx2 gather ops fail

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

> Thanks a huge to nasm64developer for the testing file.
> Are we allowed to pick it up into nasm test suite from
> license POV?

The credit goes to H.J. Lu from Intel:

  http://sourceware.org/ml/binutils/2011-06/msg00150.html

I merely converted the gas code to NASM format -- so
the original license should prevail.

Re: [Nasm-devel] [nasm:master] assemble.c: remove stray debugging code

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

On Mon, Aug 22, 2011 at 01:54:04PM -0700, nasm-bot for H. Peter Anvin wrote:
> Commit-ID:  9f2043eaad9b014f9f9d093cc0bd2137af543de1
> Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=9f2043eaad9b014f9f9d093cc0bd2137af543de1
> Author:     H. Peter Anvin <hp...@li...>
> AuthorDate: Mon, 22 Aug 2011 13:52:02 -0700
> Committer:  H. Peter Anvin <hp...@li...>
> CommitDate: Mon, 22 Aug 2011 13:52:02 -0700
> 
> assemble.c: remove stray debugging code
> 
> My bad for checking this in at all.
> 

Actually I think such snippets are quite useful since they allow to trace
the code flow, simply we need some more tunable interface with on/off trigger.
But it can wait ;)

	Cyrill