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
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




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




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




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




 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




 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 -




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




 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




 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




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

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




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




 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




 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



 

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



 

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



 

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



 

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



 

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 -



 

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



 

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



 

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



 

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

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



 

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



 

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



 

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




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




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




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




 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




 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 -




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




 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




 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




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

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




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




 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




 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




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




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




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




 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




 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 -




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




 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




 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




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

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




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




 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




 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




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




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




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




 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




 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 -




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




 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




 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




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

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




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




 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




 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




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




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




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




 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




 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 -




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




 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




 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




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

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




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




 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




 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




 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










8088

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










8088

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




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




 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










able

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










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










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




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




 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










in my

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










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










3

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

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




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










a

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










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










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,




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




 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




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




 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




 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




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




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




 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




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




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




 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")




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




 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




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




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




 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




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




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




 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")




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




 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




 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




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




 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




 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




 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




 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




 ++ 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




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




 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 *=




 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




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




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




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




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




 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




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




 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




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




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




 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




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




 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




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




 be a problem on both computers.

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




 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




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




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




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




 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




 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 -




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




 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




 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




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

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




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




 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




 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




 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







 8088

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







 8088

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




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




 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







 able

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







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




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




 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




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







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







 3

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

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




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







 a

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







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




 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




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




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




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



You're welcome!
Mar 20 2003