I'm using NASM to assemble an external function, then I link the OBJ file with the rest of DMC compiled files, but the EXE crashes (GPF, 0DH) at run. Only -mx is affected by this, -mn works fine, also tests made with Borland C++ 5.5.1, Cygwin, MinGW and DJGPP (same assembly code, NASM can generate all suitable formats).

Here's an example:

; test.asm
; use "nasm -f obj test.asm -o test.obj
segment code public use32
global _get_value
_get_value:
    push ebp
    mov ebp, esp
    mov eax, [ebp + 8]
    add eax, eax
    leave
    retn

/* main.c */
/* sc -mx main.c test.obj x32.lib */
#include <stdio.h>
unsigned get_value(unsigned);
int main(void)
{
  printf("Result is %u\n", get_value(9));
  return 0;
}

On all other configurations, the displayed value is 18, as expected.  I looked in the DMC generated code, and everything is okay (duh!).  Maybe this is a problem with the DOS extender?  Did anyone else encounter this problem? If you don't use NASM, I think my asm example should be straightforward to convert to TASM or MASM syntax.

My environment is Win2k SP2, DMC 8.26, X32 from May 15th (latest version, you know what I'm talking about).  Any feedback would be appreciated - thanks!

Is there a debugger for DOSX programs?  WUDEBUG only debugs WDOSX programs... :(

Laurentiu

Try a simple hello world program with -mx and verify that works on your system. -Walter

"Laurentiu Pancescu" <lpancescu@fastmail.fm> wrote in message news:a3c0li$2h0u$1@digitaldaemon.com...
> I'm using NASM to assemble an external function, then I link the OBJ file with the rest of DMC compiled files, but the EXE crashes (GPF, 0DH) at
run.
> Only -mx is affected by this, -mn works fine, also tests made with Borland C++ 5.5.1, Cygwin, MinGW and DJGPP (same assembly code, NASM can generate all suitable formats).
>
> Here's an example:
>
> ; test.asm
> ; use "nasm -f obj test.asm -o test.obj
> segment code public use32
> global _get_value
> _get_value:
>     push ebp
>     mov ebp, esp
>     mov eax, [ebp + 8]
>     add eax, eax
>     leave
>     retn
>
> /* main.c */
> /* sc -mx main.c test.obj x32.lib */
> #include <stdio.h>
> unsigned get_value(unsigned);
> int main(void)
> {
>   printf("Result is %u\n", get_value(9));
>   return 0;
> }
>
> On all other configurations, the displayed value is 18, as expected.  I looked in the DMC generated code, and everything is okay (duh!).  Maybe
this
> is a problem with the DOS extender?  Did anyone else encounter this
problem?
> If you don't use NASM, I think my asm example should be straightforward to convert to TASM or MASM syntax.
>
> My environment is Win2k SP2, DMC 8.26, X32 from May 15th (latest version, you know what I'm talking about).  Any feedback would be appreciated - thanks!
>
> Is there a debugger for DOSX programs?  WUDEBUG only debugs WDOSX programs... :(
>
> Laurentiu
>
>

"Walter" <walter@digitalmars.com> wrote in message news:a3csdi$4ac$1@digitaldaemon.com...
> Try a simple hello world program with -mx and verify that works on your system. -Walter

It does, and even pretty large programs, both in C and C++.  It's no problem when it's only high-level source code.  Problems arise when I try to use externally defined functions (I use NASM for portability reasons, and because of its cleaner syntax: I can use the same ASM file for any 32bit compiler, and virtually any operating system!  It's very suitable for portable MMX or 3dnow! optimizations).

It works with DMC in Win32 mode, so I think the problem is in X32, not in my code.  I "heard" about some stack alignment problems when X32 runs under real-mode DOS: maybe they're not the only ones?  Do you think I should contact Mr. Doug Hoffman about this issue?

Laurentiu

Check http://www.dosextender.com/
I think Doug Huffman put out a new version...



Laurentiu Pancescu wrote:

> "Walter" <walter@digitalmars.com> wrote in message news:a3csdi$4ac$1@digitaldaemon.com...
> > Try a simple hello world program with -mx and verify that works on your system. -Walter
>
> It does, and even pretty large programs, both in C and C++.  It's no problem when it's only high-level source code.  Problems arise when I try to use externally defined functions (I use NASM for portability reasons, and because of its cleaner syntax: I can use the same ASM file for any 32bit compiler, and virtually any operating system!  It's very suitable for portable MMX or 3dnow! optimizations).
>
> It works with DMC in Win32 mode, so I think the problem is in X32, not in my code.  I "heard" about some stack alignment problems when X32 runs under real-mode DOS: maybe they're not the only ones?  Do you think I should contact Mr. Doug Hoffman about this issue?
>
> Laurentiu

I used the latest version, when I saw those problems... it's downloaded 2 days ago, but with the same result!  It may be related to NTVDM bugs, I don't know... I'll try to boot with a DOS disk, and see if it still crashes.

Laurentiu

"Jan Knepper" <jan@smartsoft.cc> wrote in message news:3C5AAA54.88A9D7CA@smartsoft.cc...
> Check http://www.dosextender.com/
> I think Doug Huffman put out a new version...
>
>
>

 I use assembler files with x all the time. You can view them at
\dm\src\core32\*.asm and \dm\src\dos32\*.asm.

Can I suggest taking your asm file and assembling it with nasm. Try it again using dmc's inline assembler. Obj2asm the results and compare!

"Laurentiu Pancescu" <plaur@crosswinds.net> wrote in message news:a3dhlt$f8m$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:a3csdi$4ac$1@digitaldaemon.com...
> > Try a simple hello world program with -mx and verify that works on your system. -Walter
>
> It does, and even pretty large programs, both in C and C++.  It's no
problem
> when it's only high-level source code.  Problems arise when I try to use externally defined functions (I use NASM for portability reasons, and because of its cleaner syntax: I can use the same ASM file for any 32bit compiler, and virtually any operating system!  It's very suitable for portable MMX or 3dnow! optimizations).
>
> It works with DMC in Win32 mode, so I think the problem is in X32, not in
my
> code.  I "heard" about some stack alignment problems when X32 runs under real-mode DOS: maybe they're not the only ones?  Do you think I should contact Mr. Doug Hoffman about this issue?
>
> Laurentiu
>
>
>

"Walter" <walter@digitalmars.com> wrote in message news:a3fcef$rir$1@digitaldaemon.com...
> Can I suggest taking your asm file and assembling it with nasm. Try it
again
> using dmc's inline assembler. Obj2asm the results and compare!

I tried to obj2asm the object generated by NASM: I only saw db lines there, instead of actual assembly code.  So, I added 'class=CODE' in the segment declaration, and it's fine now.  Probably X32 got GPF when calling code inside of a DATA segment.  I don't understand why this is okay with all Windows compilers, including DMC, and also DJGPP (which also uses a DOS extender).  Probably it's related to how the linker and the OS loader work??

Thanks,
  Laurentiu

"Laurentiu Pancescu" <lpancescu@fastmail.fm> wrote in message news:a3gdvj$1i17$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a3fcef$rir$1@digitaldaemon.com...
> > Can I suggest taking your asm file and assembling it with nasm. Try it
> again
> > using dmc's inline assembler. Obj2asm the results and compare!
>
> I tried to obj2asm the object generated by NASM: I only saw db lines
there,
> instead of actual assembly code.  So, I added 'class=CODE' in the segment declaration, and it's fine now.  Probably X32 got GPF when calling code inside of a DATA segment.  I don't understand why this is okay with all Windows compilers, including DMC, and also DJGPP (which also uses a DOS extender).  Probably it's related to how the linker and the OS loader
work??

Glad you found what was going wrong. The reason you got the crash is X32 marks the code segment as execute only, and the data as not executable. Other dos extenders apparently don't do that.

Your solution is now in the FAQ! Thanks, -Walter

"Laurentiu Pancescu" <lpancescu@fastmail.fm> wrote in message news:a3gdvj$1i17$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a3fcef$rir$1@digitaldaemon.com...
> > Can I suggest taking your asm file and assembling it with nasm. Try it
> again
> > using dmc's inline assembler. Obj2asm the results and compare!
>
> I tried to obj2asm the object generated by NASM: I only saw db lines
there,
> instead of actual assembly code.  So, I added 'class=CODE' in the segment declaration, and it's fine now.  Probably X32 got GPF when calling code inside of a DATA segment.  I don't understand why this is okay with all Windows compilers, including DMC, and also DJGPP (which also uses a DOS extender).  Probably it's related to how the linker and the OS loader
work??
>
> Thanks,
>   Laurentiu
>
>
>

"Walter" <walter@digitalmars.com> wrote in message news:a3hkt8$232q$2@digitaldaemon.com...
> Your solution is now in the FAQ! Thanks, -Walter

Great, thanks!  And I'm also glad because my MMX code works now fine with DMC.  However, I notice that the performance of my loop is about 20% weaker than in the Borland or gcc cases (no external calls, only MOVQ, PXOR and POR!).  I expect this to be the same for any compiler, since they don't touch it.  Then, I tried to force an alignment to a paragraph border for my assembly function, but this only made things worse by an additional 10% - I guess OPTLINK knows better about alignments... :)

Is it possible that the way different runtime libraries initialize the FPU affects the MMX performance (since both MMX and FPU instructions use the same physical registers)???  There's also a slight difference between Borland and gcc generated EXEs, about 2-3% - I don't see another reason.

Laurentiu