www.digitalmars.com         C & C++   DMDScript  

c++.dos - fscanf and divide operant problem on 8088cpu - Xor.asc

reply Benoit <Benoit_member pathlink.com> writes:
The following program when compiled for the 8088 cpu and executed on intel 8088
CPU froze on the fscanf line so it never run printf("d\n"). I executed the 8088
exe program without recompilation under 286, 386 and up and it ran perfectly. I
attached the input file read by this program, it's a simple liste of numbers.

Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
same result without -o OR
with -ms instead of -ml OR
with -mld OR with or without -a2

#include <stdio.h>

int main(int argc, char **argv) {
FILE *stream;
unsigned Version;	

printf("a\n");
stream = fopen( "xor.asc", "r" );
printf("b\n");
if ( stream != NULL ) {
printf("c\n");
fscanf( stream, "%u", &Version );
printf("d\n");
}
printf("e\n");
fclose( stream );
printf("f\n");

return 0;
}

I very happy about the compiler because it's the only one I found that was able
to compile my personnal 6500lines C++ project for any CPU below 386 that
understand very well C++ templates using each other in deadlock situation.

I also found that double division like: (double)(clock_t_var_a - clock_t_var_b)
/ CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on 286 cpu
and up without recompilation... work fine on 8088 only if I remove (/
CLOCKS_PER_SEC) and just display the two clock_t value and do the divide in my
head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
Compilation parameters are the same as above except that I also tested the 3
floating point parameters(-f -ff -fd) withtout success...  

I have two XT computers, one without a 8087 coprocessor and one with it but the
divide operant froze on both... The XT computer with a 8087 is not having a
intel 8088 but a V20cpu and curiously that one is not having problem with
fscanf! I also tested reading over floppy without success, I also tested 8088 XT
with the xt v20 hardrive without success...

any idea? maybe something with the dos libraries with the 8088...

thanks...

Benoit


begin 0644 Xor.asc

`
end
Mar 12 2003
next sibling parent reply "Javier Gutiérrez" <nikkho NOSPAM hotmail.com> writes:
    Seems that the fscanf function in the library is using some kind of
186/V20 or later CPU instruction, such as SHL or SHR with an inmediate
greater than 1 or so.

    Maybe Walter could fix it.


"Benoit" <Benoit_member pathlink.com> escribió en el mensaje
news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on intel


8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed the


8088

 exe program without recompilation under 286, 386 and up and it ran


perfectly. I

 attached the input file read by this program, it's a simple liste of


numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that was


able

 to compile my personnal 6500lines C++ project for any CPU below 386 that
 understand very well C++ templates using each other in deadlock situation.

 I also found that double division like: (double)(clock_t_var_a -


clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
 Compilation parameters are the same as above except that I also tested the


3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


but the

 divide operant froze on both... The XT computer with a 8087 is not having


a

 intel 8088 but a V20cpu and curiously that one is not having problem with
 fscanf! I also tested reading over floppy without success, I also tested


8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 12 2003
next sibling parent roland <--rv ronetech.com> writes:
I noticed (DMC 8.23) that asm bswap; compiles even in <=386 cpu as asm 
cpuid; or asm rdtsc; on <= 486 cpu.
It is not correct.
One could think the <Pentium market is so small that the simplest way of 
fixing all that is to remove <Pentium cpu compilation.
May be wrong: <Pentium cpu can still exist on embeded systems and pc's 
on a chip. precisely some area where DOS is good.

roland

Javier Gutiérrez wrote:


     Seems that the fscanf function in the library is using some kind of
 186/V20 or later CPU instruction, such as SHL or SHR with an inmediate
 greater than 1 or so.
 
     Maybe Walter could fix it.
 
 
 "Benoit" <Benoit_member pathlink.com> escribió en el mensaje
 news:b4nl3s$1r1v$1 digitaldaemon.com...
 

The following program when compiled for the 8088 cpu and executed on intel


 8088
 

CPU froze on the fscanf line so it never run printf("d\n"). I executed the


 8088
 

exe program without recompilation under 286, 386 and up and it ran


 perfectly. I
 

attached the input file read by this program, it's a simple liste of


 numbers.
 

Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
same result without -o OR
with -ms instead of -ml OR
with -mld OR with or without -a2

#include <stdio.h>

int main(int argc, char **argv) {
FILE *stream;
unsigned Version;

printf("a\n");
stream = fopen( "xor.asc", "r" );
printf("b\n");
if ( stream != NULL ) {
printf("c\n");
fscanf( stream, "%u", &Version );
printf("d\n");
}
printf("e\n");
fclose( stream );
printf("f\n");

return 0;
}

I very happy about the compiler because it's the only one I found that was


 able
 

to compile my personnal 6500lines C++ project for any CPU below 386 that
understand very well C++ templates using each other in deadlock situation.

I also found that double division like: (double)(clock_t_var_a -


 clock_t_var_b)
 

/ CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


 286 cpu
 

and up without recompilation... work fine on 8088 only if I remove (/
CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


 in my
 

head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
Compilation parameters are the same as above except that I also tested the


 3
 

floating point parameters(-f -ff -fd) withtout success...

I have two XT computers, one without a 8087 coprocessor and one with it


 but the
 

divide operant froze on both... The XT computer with a 8087 is not having


 a
 

intel 8088 but a V20cpu and curiously that one is not having problem with
fscanf! I also tested reading over floppy without success, I also tested


 8088 XT
 

with the xt v20 hardrive without success...

any idea? maybe something with the dos libraries with the 8088...

thanks...

Benoit
Mar 12 2003
prev sibling parent Benoit <Benoit_member pathlink.com> writes:
I have a little more that might help Walter, if I comment the fscanf line in my
test program, the exe froze on the fclose instruction instead. Weird! I found
that one after having coded a routine to replace fscanf by a simple one reading
numbers using fgetc. My routine worked fine (so fgetc work) but I was so
surprise to see the test program froze on fclose. My previous last chance is to
code with unbuffered lower lever instructions like open, read, write, close..
will see later. My last chance will be to make a personnal lib of files IO
functions(I dont need a lot) compiled using another C compiler and link that lib
with the near perfect Digital Mars compiler, but for now, I dont know which
other old C compiler to choose to make a lib linkable with Digital Mars
compiler?

Yes, maybe there are some invalid cpu instructions inside libs for the 8088.

Benoit

In article <b4npl3$1uq8$1 digitaldaemon.com>, Javier Gutiérrez says...

    Seems that the fscanf function in the library is using some kind of
186/V20 or later CPU instruction, such as SHL or SHR with an inmediate
greater than 1 or so.

    Maybe Walter could fix it.


"Benoit" <Benoit_member pathlink.com> escribió en el mensaje
news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on intel


8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed the


8088

 exe program without recompilation under 286, 386 and up and it ran


perfectly. I

 attached the input file read by this program, it's a simple liste of


numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that was


able

 to compile my personnal 6500lines C++ project for any CPU below 386 that
 understand very well C++ templates using each other in deadlock situation.

 I also found that double division like: (double)(clock_t_var_a -


clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
 Compilation parameters are the same as above except that I also tested the


3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


but the

 divide operant froze on both... The XT computer with a 8087 is not having


a

 intel 8088 but a V20cpu and curiously that one is not having problem with
 fscanf! I also tested reading over floppy without success, I also tested


8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 12 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
It's probably generating an instruction not found on the 8088. I'll take a
look for it.

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on intel


8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed the


8088

 exe program without recompilation under 286, 386 and up and it ran


perfectly. I

 attached the input file read by this program, it's a simple liste of


numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that was


able

 to compile my personnal 6500lines C++ project for any CPU below 386 that
 understand very well C++ templates using each other in deadlock situation.

 I also found that double division like: (double)(clock_t_var_a -


clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
 Compilation parameters are the same as above except that I also tested the


3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


but the

 divide operant froze on both... The XT computer with a 8087 is not having


a

 intel 8088 but a V20cpu and curiously that one is not having problem with
 fscanf! I also tested reading over floppy without success, I also tested


8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 12 2003
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
Hmm - any way for you to load a debugger and see which instruction it is
failing on?

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on intel


8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed the


8088

 exe program without recompilation under 286, 386 and up and it ran


perfectly. I

 attached the input file read by this program, it's a simple liste of


numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that was


able

 to compile my personnal 6500lines C++ project for any CPU below 386 that
 understand very well C++ templates using each other in deadlock situation.

 I also found that double division like: (double)(clock_t_var_a -


clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
 Compilation parameters are the same as above except that I also tested the


3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


but the

 divide operant froze on both... The XT computer with a 8087 is not having


a

 intel 8088 but a V20cpu and curiously that one is not having problem with
 fscanf! I also tested reading over floppy without success, I also tested


8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 12 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
I went look at the adress of the CALL and MAYBE I found some instuctions that
are not part of the 41 instructions SET of th 8088.

C45E0A         LES   BX,[BP+0A]
99             CWD
26             ES:
98             CBW
CA0C00         RETF 000C

Benoit

In article <b4olfb$2mvq$1 digitaldaemon.com>, Walter says...

Hmm - any way for you to load a debugger and see which instruction it is
failing on?

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on intel


8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed the


8088

 exe program without recompilation under 286, 386 and up and it ran


perfectly. I

 attached the input file read by this program, it's a simple liste of


numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that was


able

 to compile my personnal 6500lines C++ project for any CPU below 386 that
 understand very well C++ templates using each other in deadlock situation.

 I also found that double division like: (double)(clock_t_var_a -


clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
 Compilation parameters are the same as above except that I also tested the


3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


but the

 divide operant froze on both... The XT computer with a 8087 is not having


a

 intel 8088 but a V20cpu and curiously that one is not having problem with
 fscanf! I also tested reading over floppy without success, I also tested


8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 12 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
Those are valid 8088 instructions. Look for maybe a shl or shr?

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

 I went look at the adress of the CALL and MAYBE I found some instuctions


that

 are not part of the 41 instructions SET of th 8088.

 C45E0A         LES   BX,[BP+0A]
 99             CWD
 26             ES:
 98             CBW
 CA0C00         RETF 000C

 Benoit

 In article <b4olfb$2mvq$1 digitaldaemon.com>, Walter says...

Hmm - any way for you to load a debugger and see which instruction it is
failing on?

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on






intel

8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed






the

8088

 exe program without recompilation under 286, 386 and up and it ran


perfectly. I

 attached the input file read by this program, it's a simple liste of


numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that






was

able

 to compile my personnal 6500lines C++ project for any CPU below 386






that

 understand very well C++ templates using each other in deadlock






situation.

 I also found that double division like: (double)(clock_t_var_a -


clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the






divide

in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000.






smile!

 Compilation parameters are the same as above except that I also tested






the

3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


but the

 divide operant froze on both... The XT computer with a 8087 is not






having

a

 intel 8088 but a V20cpu and curiously that one is not having problem






with

 fscanf! I also tested reading over floppy without success, I also






tested

8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 12 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
I found a another source of information about 8088 instruction set, yes, there
is a lot more than 41, so I saw that LES, CWD, CBW, and also SHL and SHR was
part of it.. but I didn't see ES: and RETF part of that instruction set! I
thought that C was pushing the function return value into a register before
executing RET. And what's "ES:" that is traducted from the machine code 26 by
the debugger? 

I traced the next CALL that seems to be the fclose CALL and didn't see
instruction like SHL or SHR but saw again "ES:" and RETF at the end and a lot of
other kind of CALLs in between.
Mar 13 2003
parent "Javier Gutiérrez" <nikkho NOSPAM hotmail.com> writes:
    ES: is the segment register prefix.
    RETF is only a RET with a far return.
    Both of them are supported by the 808x architecture, such as the
SHL/SRH/RCL/RCR with an inmediate of 1 or with CL register.


"Benoit" <Benoit_member pathlink.com> escribió en el mensaje
news:b4q5cb$lhj$1 digitaldaemon.com...

 I found a another source of information about 8088 instruction set, yes,


there

 is a lot more than 41, so I saw that LES, CWD, CBW, and also SHL and SHR


was

 part of it.. but I didn't see ES: and RETF part of that instruction set! I
 thought that C was pushing the function return value into a register


before

 executing RET. And what's "ES:" that is traducted from the machine code 26


by

 the debugger?

 I traced the next CALL that seems to be the fclose CALL and didn't see
 instruction like SHL or SHR but saw again "ES:" and RETF at the end and a


lot of

 other kind of CALLs in between.
Mar 13 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Which debugger are you using? Can you try SYMDEB?
Mar 13 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Ok, played with break point within symdeb and was able to execute until into the
frozen zone... Well the fclose finish with a far return (retf) that seems to not
return to the right point of return, the code executed after was not related to
the printf("f\n") that follow the fclose, may be I am not yet out of the
fclose.. whatever.. there were a INTO instruction (CE) followed by INC SP and
than 0000,E440,0000,E340,0000,0000,0000,JMP 1FFF, at 1FFF: JMP FAR CS:[1062]
where CS:1062=5541, so jumped at 5541 where this is in a black hole of 0000 for
ever... Maybe I should perhaps attach a dump of something for you.

I know that I was into the fclose because I really see the printf("e\n") work
and display "e\n" and what follow was fclose CALL preparation with one break
point right at the first instruction of that CALL destination...

need a dump of fclose?

Benoit
In article <b4qms6$14o8$1 digitaldaemon.com>, Walter says...

Which debugger are you using? Can you try SYMDEB?
Mar 13 2003
parent reply "Walter" <walter digitalmars.com> writes:
The mystery to me is that INTO is never generated by the compiler, and why
should it work on a V20? Perhaps try the divide example that's failing for
you. I don't have an 8088 machine anymore, or I'd try it myself.

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b4rnbe$1sjn$1 digitaldaemon.com...

 Ok, played with break point within symdeb and was able to execute until


into the

 frozen zone... Well the fclose finish with a far return (retf) that seems


to not

 return to the right point of return, the code executed after was not


related to

 the printf("f\n") that follow the fclose, may be I am not yet out of the
 fclose.. whatever.. there were a INTO instruction (CE) followed by INC SP


and

 than 0000,E440,0000,E340,0000,0000,0000,JMP 1FFF, at 1FFF: JMP FAR


CS:[1062]

 where CS:1062=5541, so jumped at 5541 where this is in a black hole of


0000 for

 ever... Maybe I should perhaps attach a dump of something for you.

 I know that I was into the fclose because I really see the printf("e\n")


work

 and display "e\n" and what follow was fclose CALL preparation with one


break

 point right at the first instruction of that CALL destination...

 need a dump of fclose?

 Benoit
 In article <b4qms6$14o8$1 digitaldaemon.com>, Walter says...

Which debugger are you using? Can you try SYMDEB?
Mar 13 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
My understanding is that the compiler is probably ok right now but not the
libraries containing fclose that are precompiled since I dont know when.. are
you in a position to recompile the libraries anytime? if so, I dont have a point
here... 
I will go trace the divide too.. I got an idea for the fclose cause I have two
XT computers, so, I will trace in sync in both computers at the same time and
the one with the v20 will succeed with the fclose the other will not.. I will
try to see where the major difference start to happen. 

For the divide a can do this sync trace between an XT and a 286 if I ever found
again a jmp that lost itself into the free ram otherwise is there a way for the
CPU to tell me that it just decoded an invalid instruction or if it just halt?

Benoit

In article <b4rtg9$20o2$1 digitaldaemon.com>, Walter says...

The mystery to me is that INTO is never generated by the compiler, and why
should it work on a V20? Perhaps try the divide example that's failing for
you. I don't have an 8088 machine anymore, or I'd try it myself.

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b4rnbe$1sjn$1 digitaldaemon.com...

 Ok, played with break point within symdeb and was able to execute until


into the

 frozen zone... Well the fclose finish with a far return (retf) that seems


to not

 return to the right point of return, the code executed after was not


related to

 the printf("f\n") that follow the fclose, may be I am not yet out of the
 fclose.. whatever.. there were a INTO instruction (CE) followed by INC SP


and

 than 0000,E440,0000,E340,0000,0000,0000,JMP 1FFF, at 1FFF: JMP FAR


CS:[1062]

 where CS:1062=5541, so jumped at 5541 where this is in a black hole of


0000 for

 ever... Maybe I should perhaps attach a dump of something for you.

 I know that I was into the fclose because I really see the printf("e\n")


work

 and display "e\n" and what follow was fclose CALL preparation with one


break

 point right at the first instruction of that CALL destination...

 need a dump of fclose?

 Benoit
 In article <b4qms6$14o8$1 digitaldaemon.com>, Walter says...

Which debugger are you using? Can you try SYMDEB?
Mar 14 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Well, the divide code work, the printf that follow wasn't printed because of
buffer issue I think. it's the code that follow the main { } execution that
froze the 8088 XT. I was able to compare execution on two computers and
curiously, at the end of the program the XT is jumping execution after having
execute SAR AX,04 where AX=0050 and fall on a CALL 1E5F:000C that work (and
AX=0005, that's correct) but there after two RETF jump execution into the zeroed
ram. The other computer execute SAR AX,04 and continue to the folling
instruction MOV BX,AX just after and terminate the program normally near after
that point. weird. The frozen XT have that MOV BX,AX just after SAR but never
reach it. Before the SAR we have: CWD, AND... , AND... , SAR AX,04.

Sorry, I dont have a V20, I have a V30, my mistack so, v30=16bits path instead
of 8bits path for the other 8088. If code doesn't modify itself, it should not
be a problem on both computers.

I need help to know where to put my break point to stop into the destination of
CALL FAR [0904] where DS:0904=0004, my old 8088 forze into that CALL into
another test program.


Benoit
Mar 14 2003
next sibling parent reply Benoit <Benoit_member pathlink.com> writes:
main(){} run on my XT 8088 but main() { printf("allo\n"); } froze!

Benoit
Mar 14 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Désolé d'avoir trouvé ce probleme, mais je me console car tous fonctionne bien
sur l'autre XT avec la V30 et les cpu plus recents. Je vais contourner les
problemes avec l'autre XT 8088 et de toutes facon, je vais pas faire de miracle
avec ces machines la, juste m'en servir pour optimizé la vitesse du code et la
robustesse en situation de manque de memoire RAM.

Merci pour le compilateur Digital Mars.

Changement de sujet et je devrait changer le titre si on donne suite a ce qui
suit...

Je suis obligé de faire ceci dans mon projet:

#if defined (_DIGIMARS)
typedef void(*tEl<T>::TpFct)();
#else
typedef void(tEl<T>::*TpFct)();
#endif

Si j'utilise la seconde form: tEl<T>::*TpFct, j'ai ce message du compilateur

C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
lv.h(5424) : Error: ';' expected following declaration of struct member
lv.h(5426) : Error: ';' expected following declaration of struct member
--- errorlevel 1


ET aussi

for( i = N, s = state; 
i--;
*s = oneSeed & 0xffff0000,

#if defined (_DIGIMARS) 
*s++ |= ( ((oneSeed *= 69069U) + 1) & 0xffff0000 ) >> 16, oneSeed++,
oneSeed *= 69069U, oneSeed++ ) {}
#else
*s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
(oneSeed *= 69069U)++ ) {}  // hard to read, but fast
#endif

Ci-haut, une partie de code d'un generateur aleatoire dont je ne suis pas
l'auteur et je n'est pas encore tester ma correction (code sous _DIGIMARS).

Le message du compilateur si j'utilise la seconde form:
C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
*s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
^
lv.h(220) : Error: lvalue expected
(oneSeed *= 69069U)++ ) {}  // hard to read, but fast
^
lv.h(221) : Error: lvalue expected
lv.h(317) : Error: ';' expected following declaration of struct member
lv.h(318) : Error: ';' expected following declaration of struct member
lv.h(322) : Error: ';' expected following declaration of struct member

Mes adaptations fonctionnes bien... c'est pas bien grave...

Benoit

In article <b4tpc8$d00$1 digitaldaemon.com>, Benoit says...

main(){} run on my XT 8088 but main() { printf("allo\n"); } froze!

Benoit
Mar 17 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
I'm sorry, I do not know french at all.

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

 Désolé d'avoir trouvé ce probleme, mais je me console car tous fonctionne


bien

 sur l'autre XT avec la V30 et les cpu plus recents. Je vais contourner les
 problemes avec l'autre XT 8088 et de toutes facon, je vais pas faire de


miracle

 avec ces machines la, juste m'en servir pour optimizé la vitesse du code


et la

 robustesse en situation de manque de memoire RAM.

 Merci pour le compilateur Digital Mars.

 Changement de sujet et je devrait changer le titre si on donne suite a ce


qui

 suit...

 Je suis obligé de faire ceci dans mon projet:

 #if defined (_DIGIMARS)
 typedef void(*tEl<T>::TpFct)();
 #else
 typedef void(tEl<T>::*TpFct)();
 #endif

 Si j'utilise la seconde form: tEl<T>::*TpFct, j'ai ce message du


compilateur

 C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
 lv.h(5424) : Error: ';' expected following declaration of struct member
 lv.h(5426) : Error: ';' expected following declaration of struct member
 --- errorlevel 1


 ET aussi

 for( i = N, s = state;
 i--;
 *s = oneSeed & 0xffff0000,

 #if defined (_DIGIMARS)
 *s++ |= ( ((oneSeed *= 69069U) + 1) & 0xffff0000 ) >> 16, oneSeed++,
 oneSeed *= 69069U, oneSeed++ ) {}
 #else
 *s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
 (oneSeed *= 69069U)++ ) {}  // hard to read, but fast
 #endif

 Ci-haut, une partie de code d'un generateur aleatoire dont je ne suis pas
 l'auteur et je n'est pas encore tester ma correction (code sous


_DIGIMARS).

 Le message du compilateur si j'utilise la seconde form:
 C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
 *s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
 ^
 lv.h(220) : Error: lvalue expected
 (oneSeed *= 69069U)++ ) {}  // hard to read, but fast
 ^
 lv.h(221) : Error: lvalue expected
 lv.h(317) : Error: ';' expected following declaration of struct member
 lv.h(318) : Error: ';' expected following declaration of struct member
 lv.h(322) : Error: ';' expected following declaration of struct member

 Mes adaptations fonctionnes bien... c'est pas bien grave...

 Benoit

 In article <b4tpc8$d00$1 digitaldaemon.com>, Benoit says...

main(){} run on my XT 8088 but main() { printf("allo\n"); } froze!

Benoit
Mar 17 2003
prev sibling parent reply roland <--rv ronetech.com> writes:
Benoit wrote:


 Désolé d'avoir trouvé ce probleme, mais je me console car tous fonctionne bien
 sur l'autre XT avec la V30 et les cpu plus recents. Je vais contourner les
 problemes avec l'autre XT 8088 et de toutes facon, je vais pas faire de miracle
 avec ces machines la, juste m'en servir pour optimizé la vitesse du code et la
 robustesse en situation de manque de memoire RAM.
 
 Merci pour le compilateur Digital Mars.
 
 Changement de sujet et je devrait changer le titre si on donne suite a ce qui
 suit...
 



	.
	.
	.


salut

tu veux que je fasse la traduction ?

roland
Mar 18 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Oups! funny! I forgot to switch in english! thanks Roland for your proposed help
for a translation! I was saying that it wasn't a big deal for me if the i/o
doesn't work perfectly on the 8088 because it is well working on the V30 and
other most recent one. I could perhaps go around the problem with the 8088 by
not using any i/o instructions if I really need to. Old computers are
interresting for speed optimization and to try making programs so they can run
with not enought ram. 

To anwser you about which function the SAR instruction is in, well I am not
really sur, symdeb doesn't really tell cause I ran it over an .exe program not
having symbolique information in it as used by today's debugger. Maybe someone
can help me recompile with symbolique info that symdeb might understood?
whatever, I think that the SAR instructions are into printf and into fclose. I
will try to found a way to code something that will help me figure out where the
SAR is into to be 100% sur.

I'd like to say a good thanks for that digital mars compiler.

Subject change, I should probably post what follow under a different title if
there are a need for that...

I must do the following in my project with the digital mars compiler:

#if defined (_DIGIMARS)
typedef void(*tEl<T>::TpFct)();
#else
typedef void(tEl<T>::*TpFct)();
#endif

If I use the line using tEl<T>::*TpFct like into recent compilers, then I get
the following digital mars compiler messages:
C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
lv.h(5424) : Error: ';' expected following declaration of struct member
lv.h(5426) : Error: ';' expected following declaration of struct member
--- errorlevel 1

so, I keep the _DIGIMARS(my creation) preprocessor directive defined to tell
digital mars to only compile what is above the #else.


AND ALSO,

for( i = N, s = state; 
i--;
*s = oneSeed & 0xffff0000,

#if defined (_DIGIMARS) 
*s++ |= ( ((oneSeed *= 69069U) + 1) & 0xffff0000 ) >> 16, oneSeed++,
oneSeed *= 69069U, oneSeed++ ) {}
#else
*s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
(oneSeed *= 69069U)++ ) {}  // hard to read, but fast
#endif

The above is a piece of code from a random generator that I am not the person
that wrote it. The part before the #else is my adaptation, but I still need to
verify if it is really right. But if I use the code below the #else with digital
mars, I get the following messages:

C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
*s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
^
lv.h(220) : Error: lvalue expected
(oneSeed *= 69069U)++ ) {}  // hard to read, but fast
^
lv.h(221) : Error: lvalue expected
lv.h(317) : Error: ';' expected following declaration of struct member
lv.h(318) : Error: ';' expected following declaration of struct member
lv.h(322) : Error: ';' expected following declaration of struct member

My adaptations are compiling ok and are so far well working. This is just to let
you know the minor differences I found between digital mars and other compilers
like (linux gpp, djgpp, intel icc for linux, MS visual studio 6.0 prof...) I am
using for 386 computers and above that was able to compile the code below the
#else.


Benoit

In article <3E76E3E7.8040809 ronetech.com>, roland says...

Benoit wrote:


 Désolé d'avoir trouvé ce probleme, mais je me console car tous fonctionne bien
 sur l'autre XT avec la V30 et les cpu plus recents. Je vais contourner les
 problemes avec l'autre XT 8088 et de toutes facon, je vais pas faire de miracle
 avec ces machines la, juste m'en servir pour optimizé la vitesse du code et la
 robustesse en situation de manque de memoire RAM.
 
 Merci pour le compilateur Digital Mars.
 
 Changement de sujet et je devrait changer le titre si on donne suite a ce qui
 suit...
 



	.
	.
	.


salut

tu veux que je fasse la traduction ?

roland
Mar 18 2003
next sibling parent reply Benoit <Benoit_member pathlink.com> writes:
Spaces are Stripped here, so I must precise that the up arrows are pointing the
++ signs here...

C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
*s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
.............................^
lv.h(220) : Error: lvalue expected
(oneSeed *= 69069U)++ ) {}  // hard to read, but fast
...................^
lv.h(221) : Error: lvalue expected
lv.h(317) : Error: ';' expected following declaration of struct member
lv.h(318) : Error: ';' expected following declaration of struct member
lv.h(322) : Error: ';' expected following declaration of struct member

What I understand is that calculation oneSeed *= 69069U under parenthesis must
be evaluated first and for sur the result fall into the variable oneSeed, other
recent compilers allow the ++ sign to be applied to that oneSeed variable
there after. Digital mars dont like the usage of ++ into the following
contexte:(var *= const)++ same as:(var = var * const)++ same as: var *= const,
var++.

Benoit
Mar 18 2003
parent "Walter" <walter digitalmars.com> writes:
Ok, I'll check it out. -Walter

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b57edc$qmo$1 digitaldaemon.com...

 Spaces are Stripped here, so I must precise that the up arrows are


pointing the

 ++ signs here...

 C:\dm\bin>dmc -o -ml -0 ll.cpp -oll2.exe
 *s++ |= ( (oneSeed *= 69069U)++ & 0xffff0000 ) >> 16,
 .............................^
 lv.h(220) : Error: lvalue expected
 (oneSeed *= 69069U)++ ) {}  // hard to read, but fast
 ...................^
 lv.h(221) : Error: lvalue expected
 lv.h(317) : Error: ';' expected following declaration of struct member
 lv.h(318) : Error: ';' expected following declaration of struct member
 lv.h(322) : Error: ';' expected following declaration of struct member

 What I understand is that calculation oneSeed *= 69069U under parenthesis


must

 be evaluated first and for sur the result fall into the variable oneSeed,


other

 recent compilers allow the ++ sign to be applied to that oneSeed variable
 there after. Digital mars dont like the usage of ++ into the following
 contexte:(var *= const)++ same as:(var = var * const)++ same as: var *=


const,

 var++.

 Benoit
Mar 18 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Benoit" <Benoit_member pathlink.com> wrote in message
news:b57dj4$q7m$1 digitaldaemon.com...

 To anwser you about which function the SAR instruction is in, well I am


not

 really sur, symdeb doesn't really tell cause I ran it over an .exe program


not

 having symbolique information in it as used by today's debugger. Maybe


someone

 can help me recompile with symbolique info that symdeb might understood?
 whatever, I think that the SAR instructions are into printf and into


fclose. I

 will try to found a way to code something that will help me figure out


where the

 SAR is into to be 100% sur.


Try generating a .map file (with /map to the linker). Compare the address of
the SAR with the .map file, that should tell you where it is.
Mar 18 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
The SAR AX,04 is likely the problem, as it is a value V20,V30 instruction,
but an invalid 8088 one. Does symdeb tell you which function it was in?

"Benoit" <Benoit_member pathlink.com> wrote in message
news:b4tfqn$56r$1 digitaldaemon.com...

 Well, the divide code work, the printf that follow wasn't printed because


of

 buffer issue I think. it's the code that follow the main { } execution


that

 froze the 8088 XT. I was able to compare execution on two computers and
 curiously, at the end of the program the XT is jumping execution after


having

 execute SAR AX,04 where AX=0050 and fall on a CALL 1E5F:000C that work


(and

 AX=0005, that's correct) but there after two RETF jump execution into the


zeroed

 ram. The other computer execute SAR AX,04 and continue to the folling
 instruction MOV BX,AX just after and terminate the program normally near


after

 that point. weird. The frozen XT have that MOV BX,AX just after SAR but


never

 reach it. Before the SAR we have: CWD, AND... , AND... , SAR AX,04.

 Sorry, I dont have a V20, I have a V30, my mistack so, v30=16bits path


instead

 of 8bits path for the other 8088. If code doesn't modify itself, it should


not

 be a problem on both computers.

 I need help to know where to put my break point to stop into the


destination of

 CALL FAR [0904] where DS:0904=0004, my old 8088 forze into that CALL into
 another test program.


 Benoit
Mar 17 2003
prev sibling next sibling parent reply "Nic Tiger" <nictiger progtech.ru> writes:
I don's see -0 switch in your command line. I think 8086 is not default any
more.

Nic Tiger.

"Benoit" <Benoit_member pathlink.com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ:
news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on intel


8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed the


8088

 exe program without recompilation under 286, 386 and up and it ran


perfectly. I

 attached the input file read by this program, it's a simple liste of


numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that was


able

 to compile my personnal 6500lines C++ project for any CPU below 386 that
 understand very well C++ templates using each other in deadlock situation.

 I also found that double division like: (double)(clock_t_var_a -


clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000. smile!
 Compilation parameters are the same as above except that I also tested the


3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


but the

 divide operant froze on both... The XT computer with a 8087 is not having


a

 intel 8088 but a V20cpu and curiously that one is not having problem with
 fscanf! I also tested reading over floppy without success, I also tested


8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 12 2003
parent "Javier Gutiérrez" <nikkho NOSPAM hotmail.com> writes:
    It is there: dmc -o -ml -0 tst02.cpp -otst02.exe


"Nic Tiger" <nictiger progtech.ru> escribió en el mensaje
news:b4p2g9$2vr1$1 digitaldaemon.com...

 I don's see -0 switch in your command line. I think 8086 is not default


any

 more.

 Nic Tiger.

 "Benoit" <Benoit_member pathlink.com> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ


ÓÌÅÄÕÀÝÅÅ:

 news:b4nl3s$1r1v$1 digitaldaemon.com...

 The following program when compiled for the 8088 cpu and executed on




intel

 8088

 CPU froze on the fscanf line so it never run printf("d\n"). I executed




the

 8088

 exe program without recompilation under 286, 386 and up and it ran


 perfectly. I

 attached the input file read by this program, it's a simple liste of


 numbers.

 Compiled with: dmc -o -ml -0 tst02.cpp -otst02.exe
 same result without -o OR
 with -ms instead of -ml OR
 with -mld OR with or without -a2

 #include <stdio.h>

 int main(int argc, char **argv) {
 FILE *stream;
 unsigned Version;

 printf("a\n");
 stream = fopen( "xor.asc", "r" );
 printf("b\n");
 if ( stream != NULL ) {
 printf("c\n");
 fscanf( stream, "%u", &Version );
 printf("d\n");
 }
 printf("e\n");
 fclose( stream );
 printf("f\n");

 return 0;
 }

 I very happy about the compiler because it's the only one I found that




was

 able

 to compile my personnal 6500lines C++ project for any CPU below 386 that
 understand very well C++ templates using each other in deadlock




situation.

 I also found that double division like: (double)(clock_t_var_a -


 clock_t_var_b)

 / CLOCKS_PER_SEC; froze also only with 8088 cpu and again, work well on


 286 cpu

 and up without recompilation... work fine on 8088 only if I remove (/
 CLOCKS_PER_SEC) and just display the two clock_t value and do the divide


 in my

 head, well it's easy to calculate, CLOCKS_PER_SEC is equal to 1000.




smile!

 Compilation parameters are the same as above except that I also tested




the

 3

 floating point parameters(-f -ff -fd) withtout success...

 I have two XT computers, one without a 8087 coprocessor and one with it


 but the

 divide operant froze on both... The XT computer with a 8087 is not




having

 a

 intel 8088 but a V20cpu and curiously that one is not having problem




with

 fscanf! I also tested reading over floppy without success, I also tested


 8088 XT

 with the xt v20 hardrive without success...

 any idea? maybe something with the dos libraries with the 8088...

 thanks...

 Benoit
Mar 13 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
I found the problem. Thanks for your help! It's the SAR AX,4 problem, and it
appears in several of the runtime library modules.
Mar 18 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
I've got a new sdl.lib for you to try if you send me your email
address. -Walter
Mar 18 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Wonderfull!

my email is: trembb22 hotmail.com

It will be a plesure for me to test the library!

I had already generated the map files, so I was ready to do some symdeb tonight!
will wait to test the lib first!

that's fun!

Benoit

In article <b58e8j$1khi$1 digitaldaemon.com>, Walter says...

I've got a new sdl.lib for you to try if you send me your email
address. -Walter
Mar 18 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
Hi Walter,

I tested the updated lib and one of my couple of tests programs worked fine!

I found a SAR AX,04 into the fclose(stream).

I found a (C1FA0F) SAR DX,0F into the printf("%d\n",var);

Now it is well working with base printf like: printf("string\n") along in main; 
but not with printf like printf("%d\n",var);

It's getting better, so, the SAR instructions is really the one to kill!

Benoit
Mar 19 2003
parent reply Benoit <Benoit_member pathlink.com> writes:
This is just to say thanks you to Walter and let you know that all know issues
with compiling for the 8088 platform have been fixed. It was a pleasure for me
to help, I am glad to be able to port my project to that platform with digital
mars, the only one compiler a found able to do that.

Benoit
Mar 20 2003
parent "Walter" <walter digitalmars.com> writes:
"Benoit" <Benoit_member pathlink.com> wrote in message
news:b5d34q$1ugp$1 digitaldaemon.com...

 This is just to say thanks you to Walter and let you know that all know


issues

 with compiling for the 8088 platform have been fixed. It was a pleasure


for me

 to help, I am glad to be able to port my project to that platform with


digital

 mars, the only one compiler a found able to do that.


You're welcome!
Mar 20 2003