nasm-devel — NASM development work

Re: [Nasm-devel] [PATCH] win64 fix + addition

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

On 07/01/2012 08:32 AM, Cyrill Gorcunov wrote:
> On Sun, Jul 01, 2012 at 10:13:49AM +0300, Йордан Гигов wrote:
>> The current version of Nasm never generates mod 0 rm 5 bytes to
>> address memory or code, thus it can only be linked with
>> /LARGEADDRESSAWARE:NO by the Microsoft linkers. Additionally you can't
>> specify a base larger than 0x7FFFFFFF. My patch fixes that.
>>
>> Also I make the proposition that in addition to "db", "dw", "dd",
>> "dq", etc. keywords we add "dp" (as in define pointer). It is to be
>> the same size as the program's BITS mode. In 64-bit mode it would
>> behave as dq, in 32-bit as dd, and in 16-bit as dw.
>
> I think this should be done rather by a macro definition than
> squashing into C source (and, btw don't address two problems in
> one path, it could be 2 patches -- one for sib and one for dp).
>

I think we could go either way on that... it's not a huge difference.

However, to do an if tree is kind of silly...

	-hpa

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

Re: [Nasm-devel] [PATCH] win64 fix + addition

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

On Sun, Jul 01, 2012 at 10:13:49AM +0300, Йордан Гигов wrote:
> The current version of Nasm never generates mod 0 rm 5 bytes to
> address memory or code, thus it can only be linked with
> /LARGEADDRESSAWARE:NO by the Microsoft linkers. Additionally you can't
> specify a base larger than 0x7FFFFFFF. My patch fixes that.
> 
> Also I make the proposition that in addition to "db", "dw", "dd",
> "dq", etc. keywords we add "dp" (as in define pointer). It is to be
> the same size as the program's BITS mode. In 64-bit mode it would
> behave as dq, in 32-bit as dd, and in 16-bit as dw.

I think this should be done rather by a macro definition than
squashing into C source (and, btw don't address two problems in
one path, it could be 2 patches -- one for sib and one for dp).

	Cyrill

[Nasm-devel] Forgot this

[Йордан Г. <col...@gm...>]

Last night when I submitted a patch with a fix for the addressing
problem and suggesting two new instructions I forgot about RESP. It's
the counter-part to DP.
I did not fully test it then, but now it works.
Note that these changes are only tested in win64 output. For some
reason even with the official nasm version and win32 output for 32-bit
applications the linker simply hates me.

    Signed-off-by: Jordan Gigov <col...@gm...>

diff --git a/parser.c b/parser.c
index d2d1d2c..650f751 100644
--- a/parser.c
+++ b/parser.c
@@ -947,6 +947,20 @@ is_expression:
         result->opcode = I_RESB;
         result->oprs[0].offset *= 8;
         break;
+    case I_RESP:
+        if(globalbits == 64){
+            result->opcode = I_RESB;
+            result->oprs[0].offset *= 8;
+        }
+        else if(globalbits == 32){
+            result->opcode = I_RESB;
+            result->oprs[0].offset *= 4;
+        }
+        else {
+            result->opcode = I_RESB;
+            result->oprs[0].offset *= 2;
+        }
+        break;
     case I_REST:
         result->opcode = I_RESB;
         result->oprs[0].offset *= 10;

[Nasm-devel] [PATCH] win64 fix + addition

[Йордан Г. <col...@gm...>]

The current version of Nasm never generates mod 0 rm 5 bytes to
address memory or code, thus it can only be linked with
/LARGEADDRESSAWARE:NO by the Microsoft linkers. Additionally you can't
specify a base larger than 0x7FFFFFFF. My patch fixes that.

Also I make the proposition that in addition to "db", "dw", "dd",
"dq", etc. keywords we add "dp" (as in define pointer). It is to be
the same size as the program's BITS mode. In 64-bit mode it would
behave as dq, in 32-bit as dd, and in 16-bit as dw.


    Signed-off-by: Jordan Gigov <col...@gm...>


diff --git a/assemble.c b/assemble.c
index 1a1e2df..751bd31 100644
--- a/assemble.c
+++ b/assemble.c
@@ -662,8 +662,8 @@ int64_t insn_size(int32_t segment, int64_t offset,
int bits, uint32_t cp,

     if (instruction->opcode == I_DB || instruction->opcode == I_DW ||
         instruction->opcode == I_DD || instruction->opcode == I_DQ ||
-        instruction->opcode == I_DT || instruction->opcode == I_DO ||
-        instruction->opcode == I_DY) {
+        instruction->opcode == I_DP || instruction->opcode == I_DT ||
+        instruction->opcode == I_DO || instruction->opcode == I_DY) {
         extop *e;
         int32_t isize, osize, wsize;

@@ -2311,11 +2311,10 @@ static enum ea_type process_ea(operand *input,
ea *output, int bits,
             }

             if (bits == 64 && (~input->type & IP_REL)) {
-                output->sib_present = true;
-                output->sib         = GEN_SIB(0, 4, 5);
+                output->sib_present = false;
                 output->bytes       = 4;
-                output->modrm       = GEN_MODRM(0, rfield, 4);
-                output->rip         = false;
+                output->modrm       = GEN_MODRM(0, rfield, 5);
+                output->rip         = true;
             } else {
                 output->sib_present = false;
                 output->bytes       = (addrbits != 16 ? 4 : 2);
diff --git a/insns.dat b/insns.dat
index 1f277a9..e4eb740 100644
--- a/insns.dat
+++ b/insns.dat
@@ -52,6 +52,7 @@ DB		ignore				ignore						ignore
 DW		ignore				ignore						ignore
 DD		ignore				ignore						ignore
 DQ		ignore				ignore						ignore
+DP		ignore				ignore						ignore
 DT		ignore				ignore						ignore
 DO		ignore				ignore						ignore
 DY		ignore				ignore						ignore
@@ -59,6 +60,7 @@ RESB		imm				[	resb]					8086
 RESW		ignore				ignore						ignore
 RESD		ignore				ignore						ignore
 RESQ		ignore				ignore						ignore
+RESP		ignore				ignore						ignore
 REST		ignore				ignore						ignore
 RESO		ignore				ignore						ignore
 RESY		ignore				ignore						ignore
diff --git a/nasm.c b/nasm.c
index 63e73e7..2ef802b 100644
--- a/nasm.c
+++ b/nasm.c
@@ -1673,6 +1673,17 @@ static void assemble_file(char *fname, StrList
**depend_ptr)
                                 typeinfo =

TYS_ELEMENTS(output_ins.oprs[0].offset) | TY_QWORD;
                                 break;
+                            case I_RESP:
+                                if(globalbits == 64)
+                                    typeinfo =
+
TYS_ELEMENTS(output_ins.oprs[0].offset) | TY_QWORD;
+                                else if(globalbits == 32)
+                                    typeinfo =
+
TYS_ELEMENTS(output_ins.oprs[0].offset) | TY_DWORD;
+                                else
+                                    typeinfo =
+
TYS_ELEMENTS(output_ins.oprs[0].offset) | TY_WORD;
+                                break;
                             case I_REST:
                                 typeinfo =

TYS_ELEMENTS(output_ins.oprs[0].offset) | TY_TBYTE;
@@ -1700,6 +1711,14 @@ static void assemble_file(char *fname, StrList
**depend_ptr)
                             case I_DQ:
                                 typeinfo |= TY_QWORD;
                                 break;
+                            case I_DP:
+                                if(globalbits == 64)
+                                    typeinfo |= TY_QWORD;
+                                else if(globalbits == 32)
+                                    typeinfo |= TY_DWORD;
+                                else
+                                    typeinfo |= TY_WORD;
+                                break;
                             case I_DT:
                                 typeinfo |= TY_TBYTE;
                                 break;
diff --git a/nasmlib.c b/nasmlib.c
index 2367ff3..65729a9 100644
--- a/nasmlib.c
+++ b/nasmlib.c
@@ -784,6 +784,13 @@ int idata_bytes(int opcode)
         return 4;
     case I_DQ:
         return 8;
+    case I_DP:
+        if(globalbits == 64)
+            return 8;
+        else if(globalbits == 32)
+            return 4;
+        else
+            return 2;
     case I_DT:
         return 10;
     case I_DO:
diff --git a/parser.c b/parser.c
index aa2df24..d2d1d2c 100644
--- a/parser.c
+++ b/parser.c
@@ -355,8 +355,9 @@ restart_parse:

     if (result->opcode == I_DB || result->opcode == I_DW ||
         result->opcode == I_DD || result->opcode == I_DQ ||
-        result->opcode == I_DT || result->opcode == I_DO ||
-        result->opcode == I_DY || result->opcode == I_INCBIN) {
+        result->opcode == I_DP || result->opcode == I_DT ||
+        result->opcode == I_DO || result->opcode == I_DY ||
+        result->opcode == I_INCBIN) {
         extop *eop, **tail = &result->eops, **fixptr;
         int oper_num = 0;
         int32_t sign;
@@ -364,7 +365,7 @@ restart_parse:
         result->eops_float = false;

         /*
-         * Begin to read the DB/DW/DD/DQ/DT/DO/INCBIN operands.
+         * Begin to read the DB/DW/DD/DQ/DP/DT/DO/INCBIN operands.
          */
         while (1) {
             i = stdscan(NULL, &tokval);

Re: [Nasm-devel] SF tracker turned off

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

On Fri, Mar 30, 2012 at 10:13:02AM -0700, H. Peter Anvin wrote:
> 
> There is also "Support Requests" which is horribly ill-defined and
> probably should be imported for completeness but not accept new tickets.
> 

Ah, ok.

	Cyrill

Re: [Nasm-devel] SF tracker turned off

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

On 03/30/2012 10:09 AM, Cyrill Gorcunov wrote:
> 
> There were a few bugs modification _after_ we've moved to bugzilla
> but as far as I remember I tried to update the comments in bugzilla
> manually to sync between SF and our bugzilla. But it was pain-in-ass
> exercise, which mean I really don't wanna do it again ;)
> 
> What I can do -- I can re-check comments again tomorow and try to
> figure out which of thme remained unsync'ed, ok?
> 
> As by feature requests -- they need to be imported into our bugzilla
> (which I didn't managed yet).
> 

There is also "Support Requests" which is horribly ill-defined and
probably should be imported for completeness but not accept new tickets.

	-hpa

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

Re: [Nasm-devel] SF tracker turned off

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

On Fri, Mar 30, 2012 at 09:59:05AM -0700, H. Peter Anvin wrote:
> On 03/30/2012 01:57 AM, Cyrill Gorcunov wrote:
> > On Fri, Mar 30, 2012 at 12:48:45AM -0700, anonymous coward wrote:
> >>>
> >>> Still if you have ability to export features and gimme back the
> >>> bugzilla format for it -- I would happily import it to bugzilla.nasm.us ;)
> >>
> >> XML export from SF requires admin permissions.
> > 
> > Crap, indeed. I managed to miss this fact. Well, I'll try to poke Keith
> > to grab the script he used for conversion.
> > 
> 
> Okay... how much is missing?  Specifically, what was the cutoff date?  I
> have emails for all the changes, and the only ticket that has changed
> all year is one called "PINSRB issue with 8-bit GPR".
> 
> I can also get Cyrill admin privs on SF.
> 

There were a few bugs modification _after_ we've moved to bugzilla
but as far as I remember I tried to update the comments in bugzilla
manually to sync between SF and our bugzilla. But it was pain-in-ass
exercise, which mean I really don't wanna do it again ;)

What I can do -- I can re-check comments again tomorow and try to
figure out which of thme remained unsync'ed, ok?

As by feature requests -- they need to be imported into our bugzilla
(which I didn't managed yet).

	Cyrill

Re: [Nasm-devel] SF tracker turned off

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

On 03/30/2012 01:57 AM, Cyrill Gorcunov wrote:
> On Fri, Mar 30, 2012 at 12:48:45AM -0700, anonymous coward wrote:
>>>
>>> Still if you have ability to export features and gimme back the
>>> bugzilla format for it -- I would happily import it to bugzilla.nasm.us ;)
>>
>> XML export from SF requires admin permissions.
> 
> Crap, indeed. I managed to miss this fact. Well, I'll try to poke Keith
> to grab the script he used for conversion.
> 

Okay... how much is missing?  Specifically, what was the cutoff date?  I
have emails for all the changes, and the only ticket that has changed
all year is one called "PINSRB issue with 8-bit GPR".

I can also get Cyrill admin privs on SF.

	-hpa

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

Re: [Nasm-devel] SF tracker turned off

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

On Fri, Mar 30, 2012 at 12:48:45AM -0700, anonymous coward wrote:
> >
> > Still if you have ability to export features and gimme back the
> > bugzilla format for it -- I would happily import it to bugzilla.nasm.us ;)
> 
> XML export from SF requires admin permissions.

Crap, indeed. I managed to miss this fact. Well, I'll try to poke Keith
to grab the script he used for conversion.

	Cyrill

Re: [Nasm-devel] SF tracker turned off

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

>> Yeah, there are options for auto responses as well as
>> extra text getting displayed on the tracker's webpage,
>> and you can restrict them to project members, but no
>> true read-only mode, it seems.
>>
>> Also, full XML export seems to be limited to a project
>> admin [1].
>>
>> How about importing all of the SF items into bugzilla,
>> and then just closing the SF presence down?
>>
>> [1] https://sourceforge.net/apps/trac/sourceforge/wiki/XML%20export
>
> Keith already did that for bugzilla. But it seems I missed moment
> when we should close SF, so people continue posting there (a couple
> of bug comments I think). So I guess nothing scary happen if we close
> SF now, but feature requests were never imported so this may require
> additional efforts (which for I can't spend time at moment).
>
> Still if you have ability to export features and gimme back the
> bugzilla format for it -- I would happily import it to bugzilla.nasm.us ;)

XML export from SF requires admin permissions.

Re: [Nasm-devel] SF tracker turned off

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

On Thu, Mar 29, 2012 at 11:54:11AM -0700, anonymous coward wrote:
> 
> Yeah, there are options for auto responses as well as
> extra text getting displayed on the tracker's webpage,
> and you can restrict them to project members, but no
> true read-only mode, it seems.
> 
> Also, full XML export seems to be limited to a project
> admin [1].
> 
> How about importing all of the SF items into bugzilla,
> and then just closing the SF presence down?
> 
> [1] https://sourceforge.net/apps/trac/sourceforge/wiki/XML%20export

Keith already did that for bugzilla. But it seems I missed moment
when we should close SF, so people continue posting there (a couple
of bug comments I think). So I guess nothing scary happen if we close
SF now, but feature requests were never imported so this may require
additional efforts (which for I can't spend time at moment).

Still if you have ability to export features and gimme back the
bugzilla format for it -- I would happily import it to bugzilla.nasm.us ;)

	Cyrill

Re: [Nasm-devel] SF tracker turned off

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

>> > > I've just turned off the SF tracker.
>> > > Please switch to bugzilla.nasm.us
>> >
>> > Where did the SF feature requests go?
>> >
>> > And how can one cite/reference old SF requests?
>> >
>> > Can we please bring the SF stuff back, and put it
>> > in read-only mode, rather than nuking it?
>>
>> The feature requests were not imported into bugzilla
>> (I suspect we simply missed it). I personally don't
>> know if there a way to turn SF tracker into r/o mode,
>> i'll try.
>
> So they should be back now, but there is no ro mode,
> so I fear people might continue posting bugs and feature
> requests on SF :(

Yeah, there are options for auto responses as well as
extra text getting displayed on the tracker's webpage,
and you can restrict them to project members, but no
true read-only mode, it seems.

Also, full XML export seems to be limited to a project
admin [1].

How about importing all of the SF items into bugzilla,
and then just closing the SF presence down?

[1] https://sourceforge.net/apps/trac/sourceforge/wiki/XML%20export

Re: [Nasm-devel] SF tracker turned off

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

On Thu, Mar 29, 2012 at 10:23:40PM +0400, Cyrill Gorcunov wrote:
> On Thu, Mar 29, 2012 at 11:19:44AM -0700, anonymous coward wrote:
> > > I've just turned off the SF tracker.
> > > Please switch to bugzilla.nasm.us
> > 
> > Where did the SF feature requests go?
> > 
> > And how can one cite/reference old SF requests?
> > 
> > Can we please bring the SF stuff back, and put it
> > in read-only mode, rather than nuking it?
> 
> The feature requests were not imported into bugzilla
> (I suspect we simply missed it). I personally don't
> know if there a way to turn SF tracker into r/o mode,
> i'll try.
> 

So they should be back now, but there is no ro mode,
so I fear people might continue posting bugs and feature
requests on SF :(

	Cyrill

Re: [Nasm-devel] SF tracker turned off

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

On Thu, Mar 29, 2012 at 11:19:44AM -0700, anonymous coward wrote:
> > I've just turned off the SF tracker.
> > Please switch to bugzilla.nasm.us
> 
> Where did the SF feature requests go?
> 
> And how can one cite/reference old SF requests?
> 
> Can we please bring the SF stuff back, and put it
> in read-only mode, rather than nuking it?

The feature requests were not imported into bugzilla
(I suspect we simply missed it). I personally don't
know if there a way to turn SF tracker into r/o mode,
i'll try.

	Cyrill

Re: [Nasm-devel] SF tracker turned off

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

> I've just turned off the SF tracker.
> Please switch to bugzilla.nasm.us

Where did the SF feature requests go?

And how can one cite/reference old SF requests?

Can we please bring the SF stuff back, and put it
in read-only mode, rather than nuking it?

[Nasm-devel] SF tracker turned off

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

I've just turned off the SF tracker.
Please switch to bugzilla.nasm.us

	Cyrill

Re: [Nasm-devel] NASM 2.10 released

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

On Mon, Mar 12, 2012 at 01:38:46PM -0700, H. Peter Anvin wrote:
> Hi all,
> 
> I have just pushed out NASM 2.10 as a formal release.  The build robot
> should do the build shortly.
> 

Hurrah! We did it! ;)

	Cyrill

[Nasm-devel] NASM 2.10 released

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

Hi all,

I have just pushed out NASM 2.10 as a formal release.  The build robot
should do the build shortly.

	-hpa

Re: [Nasm-devel] Ready for 2.10?

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

On Sun, Mar 11, 2012 at 05:20:06AM -0400, Frank Kotler wrote:
> Cyrill Gorcunov wrote:
> > On Sat, Mar 10, 2012 at 10:56:59PM -0800, H. Peter Anvin wrote:
> >> OK, I will try to make a 2.10 either tomorrow or on Monday.
> >>
> > 
> > Yeah.
> 
> Hardly a priority, but the help screen still fibs about "-O0" being the 
> default.
> 

Thanks for report, Frank! Just pushed out a fix.

	Cyrill

Re: [Nasm-devel] Ready for 2.10?

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

Cyrill Gorcunov wrote:
> On Sat, Mar 10, 2012 at 10:56:59PM -0800, H. Peter Anvin wrote:
>> OK, I will try to make a 2.10 either tomorrow or on Monday.
>>
> 
> Yeah.

Hardly a priority, but the help screen still fibs about "-O0" being the 
default.

Thanks, guys!

Best,
Frank

Re: [Nasm-devel] Ready for 2.10?

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

On Sat, Mar 10, 2012 at 10:56:59PM -0800, H. Peter Anvin wrote:
> 
> OK, I will try to make a 2.10 either tomorrow or on Monday.
> 

Yeah.

	Cyrill

Re: [Nasm-devel] Ready for 2.10?

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

On 03/10/2012 10:55 PM, Cyrill Gorcunov wrote:
> On Sat, Mar 10, 2012 at 03:13:30PM -0800, H. Peter Anvin wrote:
>> I would like to make a 2.10 release as soon as possible.  Anyone who
>> feels that what we have in 2.10rc15 still needs work or testing?
>>
> 
> I think we're in good shape at moment.
> 
> 	Cyrill

OK, I will try to make a 2.10 either tomorrow or on Monday.

	-hpa

Re: [Nasm-devel] Ready for 2.10?

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

On Sat, Mar 10, 2012 at 03:13:30PM -0800, H. Peter Anvin wrote:
> I would like to make a 2.10 release as soon as possible.  Anyone who
> feels that what we have in 2.10rc15 still needs work or testing?
> 

I think we're in good shape at moment.

	Cyrill

[Nasm-devel] Ready for 2.10?

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

I would like to make a 2.10 release as soon as possible.  Anyone who
feels that what we have in 2.10rc15 still needs work or testing?

	-hpa

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

[Nasm-devel] NASM 2.10rc14 tagged -- let's try for release

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

Let's see if we can take the build currently tagged as 2.10rc14 and turn
it into 2.10 by the end of the week.

	-hpa