www.digitalmars.com         C & C++   DMDScript  

c++.dos.16-bits - 8086 froze on long variable usage

reply Benoit <Benoit_member pathlink.com> writes:
Hi,

I had to change one variable from an int to a long in my project. The resulted
compiled program started to froze.. I then did some symdeb traces between two
computer executing the same .exe.

- at one point the 8088 computer jumped over a MOV instruction after having
execute POP ES where the other computer, a 286, didn't and executed the next MOV
instruction.

:01A1 07.....POP ES
:01A2 B9000C MOV CX,0C00
:01A5 BFF20A SUB CX,DI

- another test show under symdeb that my 8088 froze on fourth PUSH [0260]

- another test show again a jump over CLI instruction after having execute: MOV
ES, [0638], the CLI instruction that follow was never executed on the 8088 and
was on the V30 and up.

dmc -o -ml -0 tst04.cpp -otst04.exe

#define UCHAR_MAX 255U
#define TULONG unsigned long
time_t t;
register size_t i;
register TULONG h1 = 0;
register unsigned char *p = (unsigned char *) &t;
for (i=0; i < sizeof(t); i++) {
h1 *= UCHAR_MAX + 2U;
h1 += p[i];
}

curiously the above program never increment i (i++ into the for) and an infini
loop occur on a 8088 but it ran well under a 286.

Benoit
Apr 07 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
I'll check it out. -Walter
Apr 07 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
Can you please provide self-contained examples of each of these? Thanks!

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b6sccs$6nt$1 digitaldaemon.com...

 Hi,

 I had to change one variable from an int to a long in my project. The


resulted

 compiled program started to froze.. I then did some symdeb traces between


two

 computer executing the same .exe.

 - at one point the 8088 computer jumped over a MOV instruction after


having

 execute POP ES where the other computer, a 286, didn't and executed the


next MOV

 instruction.

 :01A1 07.....POP ES
 :01A2 B9000C MOV CX,0C00
 :01A5 BFF20A SUB CX,DI

 - another test show under symdeb that my 8088 froze on fourth PUSH [0260]

 - another test show again a jump over CLI instruction after having


execute: MOV

 ES, [0638], the CLI instruction that follow was never executed on the 8088


and

 was on the V30 and up.

 dmc -o -ml -0 tst04.cpp -otst04.exe

 #define UCHAR_MAX 255U
 #define TULONG unsigned long
 time_t t;
 register size_t i;
 register TULONG h1 = 0;
 register unsigned char *p = (unsigned char *) &t;
 for (i=0; i < sizeof(t); i++) {
 h1 *= UCHAR_MAX + 2U;
 h1 += p[i];
 }

 curiously the above program never increment i (i++ into the for) and an


infini

 loop occur on a 8088 but it ran well under a 286.

 Benoit
Apr 07 2003
prev sibling parent reply "Javier Gutiérrez" <nikkho NOSPAM hotmail.com> writes:
    The problems seems to be that 8088 and 8086 do not support pushing an
inmediate such as PUSH [0260], it should be replaced with a code in the way
of MOV AX, [0260]; PUSH AX.

"Benoit" <Benoit_member pathlink.com> escribió en el mensaje
news:b6sccs$6nt$1 digitaldaemon.com...

 Hi,

 I had to change one variable from an int to a long in my project. The


resulted

 compiled program started to froze.. I then did some symdeb traces between


two

 computer executing the same .exe.

 - at one point the 8088 computer jumped over a MOV instruction after


having

 execute POP ES where the other computer, a 286, didn't and executed the


next MOV

 instruction.

 :01A1 07.....POP ES
 :01A2 B9000C MOV CX,0C00
 :01A5 BFF20A SUB CX,DI

 - another test show under symdeb that my 8088 froze on fourth PUSH [0260]

 - another test show again a jump over CLI instruction after having


execute: MOV

 ES, [0638], the CLI instruction that follow was never executed on the 8088


and

 was on the V30 and up.

 dmc -o -ml -0 tst04.cpp -otst04.exe

 #define UCHAR_MAX 255U
 #define TULONG unsigned long
 time_t t;
 register size_t i;
 register TULONG h1 = 0;
 register unsigned char *p = (unsigned char *) &t;
 for (i=0; i < sizeof(t); i++) {
 h1 *= UCHAR_MAX + 2U;
 h1 += p[i];
 }

 curiously the above program never increment i (i++ into the for) and an


infini

 loop occur on a 8088 but it ran well under a 286.

 Benoit
Apr 08 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Hi, here my test program compiled like mentionned in my previous memo:

#include <stdio.h>
#include <time.h>
#define UCHAR_MAX 255U
#define TLONG unsigned long
void main(int argc, char **argv) {
time_t t;
register TLONG h1 = 0;
register size_t i;
register unsigned char *p = (unsigned char *) &t;
printf("begin\n");
for (i=0; i < sizeof(t); i++)
{
h1 *= UCHAR_MAX + 2U;
h1 += p[i];
}
printf("end\n");
}

Here one curious think a found with symdeb:

:0167 CD21 INT 21
:0169 1E   PUSH D5
:016A 07   POP ES
:016B 7307 JNB 0174
:0174 C70630050000 MOV Word Ptr [0530],0000 DS:0530=0001

On the 8088 cpu, JNB 0174 is never executed cause POP ES is jumping over it on
the MOV instruction... Where on a 286, the JNB 0174 is well executed after the
POP ES.

Sorry for the delay, my sick baby girl is taking me all my times... and my boy
just started a fiever tonight... that's life!

see you back soon...

Benoit
Apr 08 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Benoit" <Benoit_member pathlink.com> wrote in message
news:b6vqh2$2o38$1 digitaldaemon.com...

 Hi, here my test program compiled like mentionned in my previous memo:

 #include <stdio.h>
 #include <time.h>
 #define UCHAR_MAX 255U
 #define TLONG unsigned long
 void main(int argc, char **argv) {
 time_t t;
 register TLONG h1 = 0;
 register size_t i;
 register unsigned char *p = (unsigned char *) &t;
 printf("begin\n");
 for (i=0; i < sizeof(t); i++)
 {
 h1 *= UCHAR_MAX + 2U;
 h1 += p[i];
 }
 printf("end\n");
 }

 Here one curious think a found with symdeb:

 :0167 CD21 INT 21
 :0169 1E   PUSH D5
 :016A 07   POP ES
 :016B 7307 JNB 0174
 :0174 C70630050000 MOV Word Ptr [0530],0000 DS:0530=0001

 On the 8088 cpu, JNB 0174 is never executed cause POP ES is jumping over


it on

 the MOV instruction... Where on a 286, the JNB 0174 is well executed after


the

 POP ES.


Those instructions are not generated by the code you presented (you can
verify this by running obj2asm on the .obj file). The symdeb dump lists all
valid 8088 instructions, so I don't know what could be wrong. I don't think
the JNB is being jumped over, it is a jump not taken if the Carry flag is
clear.
Apr 08 2003
parent reply benoit <benoit_member pathlink.com> writes:
ok, i will check better. one think for sur, if I replace:

#define TLONG unsigned long

by

#define TLONG unsigned int

the resulted exe run ok instead of displaying garbage into the screen or froze
the computer... so there is something about the long type usage!

I will try to understand better with a look to the obj to asm generated and
compare with symdeb.

by back later... bye

Benoit

In article <b707j8$30sj$1 digitaldaemon.com>, Walter says...

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b6vqh2$2o38$1 digitaldaemon.com...

 Hi, here my test program compiled like mentionned in my previous memo:

 #include <stdio.h>
 #include <time.h>
 #define UCHAR_MAX 255U
 #define TLONG unsigned long
 void main(int argc, char **argv) {
 time_t t;
 register TLONG h1 = 0;
 register size_t i;
 register unsigned char *p = (unsigned char *) &t;
 printf("begin\n");
 for (i=0; i < sizeof(t); i++)
 {
 h1 *= UCHAR_MAX + 2U;
 h1 += p[i];
 }
 printf("end\n");
 }

 Here one curious think a found with symdeb:

 :0167 CD21 INT 21
 :0169 1E   PUSH D5
 :016A 07   POP ES
 :016B 7307 JNB 0174
 :0174 C70630050000 MOV Word Ptr [0530],0000 DS:0530=0001

 On the 8088 cpu, JNB 0174 is never executed cause POP ES is jumping over


it on

 the MOV instruction... Where on a 286, the JNB 0174 is well executed after


the

 POP ES.


Those instructions are not generated by the code you presented (you can
verify this by running obj2asm on the .obj file). The symdeb dump lists all
valid 8088 instructions, so I don't know what could be wrong. I don't think
the JNB is being jumped over, it is a jump not taken if the Carry flag is
clear.
Apr 09 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
ok, I found something right into the compiled of tst04.cpp code I made:

The compiled program is the following:
dmc -o -ml -gl -0 tst04.cpp -otst04.exe -L/map
obj2asm tst04 -ctst04

#include <stdio.h>
#include <time.h>
#ifndef UCHAR_MAX
#define UCHAR_MAX		255U
#endif
#define TLONG		unsigned long // int // long
void main(int argc, char **argv) {
time_t t; // clock_t c;
register TLONG h1 = 0;
register size_t i;
register unsigned char *p = (unsigned char *) &t;
for (i=0; i < sizeof(t); i++)
{
h1 *= UCHAR_MAX + 2U;
h1 += p[i];
}
printf("%d\n",i);
}

I had trouble to Breakpoint into the right call with symdeb but finally found
the right place where I could see my test program ASM instructions execute.

This following portion of tst04.cod is after the call to the external
long_multiply routine. There is a SAR instruction that caused a big jump with
the 8088 XT computer.
;		h1 += p[i];
mov	AL,SS:[SI]
xor	AH,AH
mov	DX,AX
sar	DX,0Fh
add	-4[BP],AX

with symdeb I saw the following..

:002f 89c2 MOV DX,AX
:0031 C1FA0F SAR DX,0F
:0034 0146FC ADD [BP-04],AX not executed, instead fall at :0BE1 0E PUSH CI

the ADD [BP-04],AX was executed ok after the SAR on the V30 and up

Benoit
Apr 10 2003
next sibling parent "Javier Gutiérrez" <nikkho NOSPAM hotmail.com> writes:
 Yes, SAR with an inmediate different thant 1 is not supported in CPU lower
than a 186.

 Seems a bug in the DMC code generator.


"Benoit" <Benoit_member pathlink.com> escribió en el mensaje
news:b7445e$2meb$1 digitaldaemon.com...

 ok, I found something right into the compiled of tst04.cpp code I made:

 The compiled program is the following:
 dmc -o -ml -gl -0 tst04.cpp -otst04.exe -L/map
 obj2asm tst04 -ctst04

 #include <stdio.h>
 #include <time.h>
 #ifndef UCHAR_MAX
 #define UCHAR_MAX 255U
 #endif
 #define TLONG unsigned long // int // long
 void main(int argc, char **argv) {
 time_t t; // clock_t c;
 register TLONG h1 = 0;
 register size_t i;
 register unsigned char *p = (unsigned char *) &t;
 for (i=0; i < sizeof(t); i++)
 {
 h1 *= UCHAR_MAX + 2U;
 h1 += p[i];
 }
 printf("%d\n",i);
 }

 I had trouble to Breakpoint into the right call with symdeb but finally


found

 the right place where I could see my test program ASM instructions


execute.

 This following portion of tst04.cod is after the call to the external
 long_multiply routine. There is a SAR instruction that caused a big jump


with

 the 8088 XT computer.
 ; h1 += p[i];
 mov AL,SS:[SI]
 xor AH,AH
 mov DX,AX
 sar DX,0Fh
 add -4[BP],AX

 with symdeb I saw the following..

 :002f 89c2 MOV DX,AX
 :0031 C1FA0F SAR DX,0F
 :0034 0146FC ADD [BP-04],AX not executed, instead fall at :0BE1 0E PUSH CI

 the ADD [BP-04],AX was executed ok after the SAR on the V30 and up

 Benoit
Apr 10 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
The sar instruction is clearly the problem, but where is it? Here's the code
I get when compiled using those flags:

-------------------------------------------
;void main(int argc, char **argv) {
_main:
                push    BP
                mov     BP,SP
                sub     SP,0Ah
                push    SI
;time_t t; // clock_t c;
;register TLONG h1 = 0;
                mov     word ptr -4[BP],0
                mov     word ptr -2[BP],0
;register size_t i;
;register unsigned char *p = (unsigned char *) &t;
                lea     SI,-8[BP]
;for (i=0; i < sizeof(t); i++)
;{
;h1 *= UCHAR_MAX + 2U;
L14:            mov     BX,0101h
                xor     CX,CX
                mov     AX,-4[BP]
                mov     DX,-2[BP]
                call    far ptr __LMUL 
                mov     -4[BP],AX
                mov     -2[BP],DX
;h1 += p[i];
                mov     AL,SS:[SI]
                xor     AH,AH
                test    AX,AX
                cwd
                add     -4[BP],AX
                adc     -2[BP],DX
                inc     SI
                lea     AX,-4[BP]
                cmp     SI,AX
                jb      L14
;}
;printf("%d\n",i);
                mov     AX,SI
                lea     CX,-8[BP]
                sub     AX,CX
                push    AX
                push    DS
                mov     AX,offset DGROUP:_DATA
                push    AX
                call    far ptr _printf
                add     SP,6
                xor     AX,AX
;}
                pop     SI
                mov     SP,BP
                pop     BP
                retf
TEST_TEXT       ends
-------------------------------------


"Benoit" <Benoit_member pathlink.com> wrote in message
news:b7445e$2meb$1 digitaldaemon.com...

 ok, I found something right into the compiled of tst04.cpp code I made:

 The compiled program is the following:
 dmc -o -ml -gl -0 tst04.cpp -otst04.exe -L/map
 obj2asm tst04 -ctst04

 #include <stdio.h>
 #include <time.h>
 #ifndef UCHAR_MAX
 #define UCHAR_MAX 255U
 #endif
 #define TLONG unsigned long // int // long
 void main(int argc, char **argv) {
 time_t t; // clock_t c;
 register TLONG h1 = 0;
 register size_t i;
 register unsigned char *p = (unsigned char *) &t;
 for (i=0; i < sizeof(t); i++)
 {
 h1 *= UCHAR_MAX + 2U;
 h1 += p[i];
 }
 printf("%d\n",i);
 }

 I had trouble to Breakpoint into the right call with symdeb but finally


found

 the right place where I could see my test program ASM instructions


execute.

 This following portion of tst04.cod is after the call to the external
 long_multiply routine. There is a SAR instruction that caused a big jump


with

 the 8088 XT computer.
 ; h1 += p[i];
 mov AL,SS:[SI]
 xor AH,AH
 mov DX,AX
 sar DX,0Fh
 add -4[BP],AX

 with symdeb I saw the following..

 :002f 89c2 MOV DX,AX
 :0031 C1FA0F SAR DX,0F
 :0034 0146FC ADD [BP-04],AX not executed, instead fall at :0BE1 0E PUSH CI

 the ADD [BP-04],AX was executed ok after the SAR on the V30 and up

 Benoit
Apr 10 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Well, I am not generating the same things! 

The last time we worked together abour the SAR instruction, they were only some
libraries fixed I received. It seems clear now, for me, that I dont have the
last version of the compiler!

ok, I am going to go get the last version and recompile!

Benoit
Apr 10 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
so sorry to have lost some of your times!

It's ok now with the last compiler version! I was still using 8.32!

Hop that I wont make that mistack again...

bye

Benoit

In article <b74c50$2rq2$1 digitaldaemon.com>, Benoit says...

Well, I am not generating the same things! 

The last time we worked together abour the SAR instruction, they were only some
libraries fixed I received. It seems clear now, for me, that I dont have the
last version of the compiler!

ok, I am going to go get the last version and recompile!

Benoit
Apr 10 2003
parent "Walter" <walter digitalmars.com> writes:
I wish most problems were resolved this easilly!

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b74d3e$2sah$1 digitaldaemon.com...

 so sorry to have lost some of your times!

 It's ok now with the last compiler version! I was still using 8.32!

 Hop that I wont make that mistack again...

 bye

 Benoit

 In article <b74c50$2rq2$1 digitaldaemon.com>, Benoit says...

Well, I am not generating the same things!

The last time we worked together abour the SAR instruction, they were




only some

libraries fixed I received. It seems clear now, for me, that I dont have




the

last version of the compiler!

ok, I am going to go get the last version and recompile!

Benoit
Apr 10 2003