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.

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

Which debugger are you using? Can you try SYMDEB?

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

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

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

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

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

Benoit

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

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