Jump to page: 1 2
Thread overview
8086 froze on long variable usage
Apr 07, 2003
Benoit
Apr 07, 2003
Walter
Apr 07, 2003
Walter
Apr 08, 2003
Javier Gutiérrez
Apr 09, 2003
Benoit
Apr 09, 2003
Walter
Apr 09, 2003
benoit
Apr 10, 2003
Benoit
Apr 10, 2003
Javier Gutiérrez
Apr 10, 2003
Walter
Apr 10, 2003
Benoit
Apr 10, 2003
Benoit
Apr 11, 2003
Walter
April 07, 2003
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


April 07, 2003
I'll check it out. -Walter


April 07, 2003
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
>
>


April 08, 2003
    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
>
>


April 09, 2003
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


April 09, 2003
"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.


April 09, 2003
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.
>
>


April 10, 2003
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


April 10, 2003
 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
>
>


April 10, 2003
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
>
>


« First   ‹ Prev
1 2