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

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

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
>

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

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

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

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.

I've got a new sdl.lib for you to try if you send me your email address. -Walter

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

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