From: "Tanes Sriviroolchai" Newsgroups: comp.os.msdos.djgpp References: <7sul6k$l1n$1 AT dove DOT qut DOT edu DOT au> Subject: Re: asm errors compiling grx Date: Mon, 4 Oct 1999 11:02:25 +0700 Lines: 155 X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Original-NNTP-Posting-Host: 192.127.136.173 Message-ID: <37f829ca@rpc1284.daytonoh.ncr.com> NNTP-Posting-Host: ncrnews.daytonoh.ncr.com X-Trace: 4 Oct 1999 00:15:04 -0500, ncrnews.daytonoh.ncr.com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com I think you are using gcc 2.95. If you use gcc 2.8.1 or gcc 2.7.2.x, you will have no problem. Below is the explanation why gcc 2.95 issues error while compiling those codes: Regards, Tanes Sriviroolchai ----- Start explanation ----- Why gcc 2.95 issues that error can explain by these statements that extracted from http://gcc.gnu.org/faq.html Problems with invalid `asm' statements Previous releases of GCC (for example, GCC 2.7.2 or EGCS 1.1.2) did not detect as invalid a clobber specifier that clobbered an operand. Instead, it could spuriously and silently generate incorrect code for certain non-obvious cases of source code. Even more unfortunately, the manual (Using and Porting GCC, section Extended Asm, see the bug report entry) did not explicitly say that it was invalid to specify clobber registers that were destined to overlap operands; it could arguably be interpreted that it was correct to clobber an input operand to mark it as not holding a usable value after the asm. For the general case, there is no way to tell whether a specified clobber is intended to overlap with a specific (input) operand or is a program error, where the choice of actual register for operands failed to avoid the clobbered register. Such unavoidable overlap is detected by versions GCC 2.95 and newer, and flagged as an error rather than accepted. An error message is given, such as: foo.c: In function `foo': foo.c:7: Invalid `asm' statement: foo.c:7: fixed or forbidden register 0 (ax) was spilled for class AREG. Unfortunately, a lot of existing software, for example the Linux kernel version 2.0.35 for the Intel x86, has constructs where input operands are marked as clobbered. The manual now describes how to write constructs with operands that are modified by the construct, but not actually used. To write an asm which modifies an input operand but does not output anything usable, specify that operand as an output operand outputting to an unused dummy variable. In the following example for the x86 architecture (taken from the Linux 2.0.35 kernel -- include/asm-i386/delay.h), the register-class constraint "a" denotes a register class containing the single register "ax" (aka. "eax"). It is therefore invalid to clobber "ax"; this operand has to be specified as an output as well as an input. The following code is therefore invalid: extern __inline__ void __delay (int loops) { __asm__ __volatile__ (".align 2,0x90\n1:\tdecl %0\n\tjns 1b" : /* no outputs */ : "a" (loops) : "ax"); } It could be argued that since the register class for "a" contains only a single register, this could be detected as an "obvious" intended clobber of the input operand. While that is feasible, it opens up for further "obvious" cases, where the level of obviousness changes from person to person. As there is a correct way to write such asm constructs, this obviousness-detection is not needed other than for reasons of compatibility with an existing code-base, and that code base can be corrected. This corrected and clobber-less version, is valid for GCC 2.95 as well as for previous versions of GCC and EGCS: extern __inline__ void __delay (int loops) { int dummy; __asm__ __volatile__ (".align 2,0x90\n1:\tdecl %0\n\tjns 1b" : "=a" (dummy) : "0" (loops)); } Note that the asm construct now has an output operand, but it is unused. Normally asm constructs with only unused output operands may be removed by gcc, unless marked volatile as above ----- End explanation ----- Chris Ho-Stuart wrote in message news:7sul6k$l1n$1 AT dove DOT qut DOT edu DOT au... > I am trying to compile the grx library on a pentium166 WindowsNT box > using make from a dos command window. > > I unzip the files for grx23, cd to the src directory, and run > > make -f makefile.dj2 > > After lots of compilation it ends up with > > gcc -c -O6 -Wall -fomit-frame-pointer -I. -I./include -I../include -I../addo ns/print -I../addons/bmp user/uellia.c -o user/uellia.o > Load error: no DOS memory. > > But that is not the problem... I restart make, and it proceeds through > the uellia just fine the second time. > > The real problem is at this point.... > > gcc -c -O6 -Wall -fomit-frame-pointer -I. -I./include -I../include -I../addo ns/print -I../addons/bmp utils/shiftscl.c -o utils/shiftscl.o > utils/shiftscl.c: In function `_GR_shift_scanline': > utils/shiftscl.c:48: Invalidm' statement: > utils/shiftscl.c:48: fixed or forbidden register 2 (cx) was spilled for class CREG. > utils/shiftscl.c:102: Invalidm' statement: > utils/shiftscl.c:102: fixed or forbidden register 2 (cx) was spilled for class CREG. > make.exe: *** [utils/shiftscl.o] Error 1 > > Any help gratefully accepted. > > Further info... > > Line 48 in utils/shiftscl.c is the asm statement in the following > context... > > . > . > . > GR_int8u far *d = *(dst++) + ws; > # if defined(__GNUC__) && defined(__i386__) > int w = ws; > /* sad but true: the x86 bytesex forces this inefficient code ( */ > asm volatile ("\n" > " movb (%3),%%ch \n" > " jmp 1f \n" > " .align 4,0x90 \n" > "1: decl %3 \n" > " movb %%ch,%%al \n" > " movb (%3),%%ah \n" > " movb %%ah,%%ch \n" > " shrl %%cl,%%eax \n" > " movb %%al,(%4) \n" > " decl %4 \n" > " decl %5 \n" > " jne 1b \n" > " shrb %%cl,%%ch \n" > " movb %%ch,(%4) " > : "=r" ((void *)s), "=r" ((void *)d), "=r" ((int)w) > : "0" ((void *)s), "1" ((void *)d), "2" ((int)w), "c" ((int)shift) > : "ax", "cx" > ); > # elif defined(__TURBOC__) > . > . > . > > Thanks -- Chris Ho-Stuart