From: Robert Bruce <wyvern AT mbay DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: NEED HELP WITH GRX
Date: Sat, 18 Mar 2000 10:11:56 -0800
Organization: Posted via Supernews, http://www.supernews.com
Lines: 65
Message-ID: <pgg7dssolk4bv09ihpfod5a51iot2bgb69@4ax.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000314095102 DOT 4527I-100000 AT is> <38D0C9F8 DOT 40BECC63 AT ujf-grenoble DOT fr> <8aqsuf$42fh4$1 AT fu-berlin DOT de> <38D16047 DOT 3C9F9A95 AT ujf-grenoble DOT fr> <pv06ds0qo1kgc56j63jakv9q7rj4mqq198 AT 4ax DOT com> <8avn7q$49908$1 AT fu-berlin DOT de>
X-Complaints-To: newsabuse AT supernews DOT com
X-Newsreader: Forte Agent 1.7/32.534
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Dieter,

I really don't know if I am lying to the compiler or not,  I "do" know
that the patch in the FAQ produces code that produces an immediate GPF
on my system.  I "do" know that the code I listed in my initial reply
produces code that executes correctly on my system.  Don't know what
else I can say.  

One thing to note "c" is listed as an input register,  I would hardly
think that the compiler will assume that the code didn't change the
input registers.

I believe that is why the compiler rejects the orginal code and also
why the patch causes a problem.  A register cannot be input or output
and clobbered. (? since 2.95.2)

My interpretation of Brennans Tutorial is that the clobbered list
should hold registers that are neither input or output but are
modified.  Since "c" is specified as an input it is by definition
modified by the asm code.

As a general note if I trust the tool (a sometimes mistaken
assumption) just removing an offending statement frequently results in
correct behaviour.

Regards,
Robert Bruce

On 18 Mar 2000 10:53:46 GMT, buers AT gmx DOT de (Dieter Buerssner) wrote:

>Robert Bruce wrote:
>
>>I tried the patches also and ran into the same problem you are seeing,
>>the solution was obvious after the fact.  If the assembler says it
>>shouldn't be there then just remove it.  The cause of the problem has
>>to do with the assembler/compiler automagically tagging the register
>>as dirty and it apparently resents us trying to tell it what to do in
>>cases like that.
>>
>>here is what the working version on my system looks like.
>>       : "=r" ((void *)s), "=r" ((void *)d), "=r" ((int)w)/*,"=cx"
>>(dummy)*/
>>       : "0" ((void *)s), "1" ((void *)d), "2" ((int)w), "c"
>>((int)shift)
>>       : "ax"
>>
>>The "c" also refers to the cx/ecx register so that is all the notice
>>the compiler wants or needs.
>
>This may work by accident only. You are lying to the compiler.
>It is free to assume that register ecx is kept const, so when
>the variable shift is used again, the compiler can assume, that
>it is still unchanged in the register. But the code destroys
>the cx register. This was indicated by the 'old' method to
>put the register on the clobbered list. But this is forbidden
>for input registers in gcc 2.95. So the workaround with
>dummy variables in the output list.
>
>Also note, that you just cannot comment in and out /*,"=cx" (dummmy) */
>This needs renumbering of the registers in the asm code.
>With ,"=c" (dummy), the "c" ((int)shift) should read "3" (shift).
>
>Regards,
>Dieter