I'm trying to compile grub-legacy using gcc-4.5.3/binutils-2.21.53.0.2 am getting this error during compilation:
Error: Operand type mismatch for 'and'
The offending lines are like this:
Searching for "Operand type mismatch for 'and'" hasn't helped. Does anyone have any idea what is wrong here?

Hi there,

first of all, that seems a strange syntax to me. Totally different to what I'm used to. I guess that instruction would "normally" be

and si,0xFFFFFFFF

And as you can see, that tries to involve a 16bit register and a 32bit constant. That can't be right.

Besides, hexadecimal numbers are prefixed with 0x or, less frequently, a dollar sign - but not both at the same time. Another common way to indicate hexadecimal numbers, especially in Assembler, is a trailing 'h'.

[X] Doc CPU

Must be the 32bits Slackware-current ? The 64bits OS would say :
C compiler cannot create executables.

Issues are expected, I guess : The grub-0.97 code is from year 2003.
Most OS' use older grub packages for the latest OS version.
Example: "slackware-current/extra/grub/grub-0.97-i486-9.txz" : 14-May-2010.
And : Debian (Wheezy) has "gcc-4.3" as a dependency for building grub-legacy.

Fedora 16 has patches, that will fix the issues for 32bits Slackware-current :
1) 0001-Fall-back-to-old-efi-GOP-detection-behavior.patch
2) 0001-Fix-strange-compilation-problem.patch
3) grub-fedora-16.patch : 1.7 MB / 47,000 lines.
→ → gcc-4.5.3 will do OK.
http://download.fedora.redhat.com/pu...9.fc16.src.rpm
> > grub-0.97-79.fc16.src.rpm

.

What you call "normal" is Intel syntax, the "strange" syntax is AT&T which is what (g)as uses. See AT&T Syntax versus Intel Syntax.

16bit registers!? esi is the 32bit version of si, and rsi is the 64bit one.

"Must be the 32bits Slackware-current ?" No, but I expect they would have the same problem if they tried to re-compile grub-0.97 right now. It turns out to be the binutils version causing the problem. Thanks knudfl for the link to the latest fedora rpm -I had already found a couple for ~fc13 to look for corrective patches to the source itself.

"gcc-4.3 as a dependency" I keep 4.2.1 around for anything pretty old. In fact I keep 3.4.6 around for one favorite 'oldy'.

Meanwhile, I'll look for another binutils version which matches well with gcc-4.5.3/glibc-2.13. I'd like to find a single combination which works well for both ix86 and ARM arches. I'm upgrading from glibc-2.11.1/gcc-4.4.3/binutils-2.19.
I'm consulting crosstool-ng's 'status' table for clues regarding arm. ANyone have a better idea?

Since your immediate data operand only specifies 32 bits, and the MSB is a 'one', I would hazard a guess that the assembler cannot decide whether the operand should be extended to '00000000FFFFFFFF' or 'FFFFFFFFFFFFFFFF', or something else altogether.
--- rod.

In the x86_64 machine language, an immediate data operand to a 64 bit AND instruction can only be an 8-bit or 32-bit value sign extended to 64-bit.

0x00000000FFFFFFFF is not a possible operand for that instruction.

So my guess is this instruction is incorrect and the assembler is correct to reject it. I don't know for sure. Maybe the rules of the assembler are the same as the rules of the machine language that writing a 32 bit constant in a 64 bit AND instruction inherently means the 64 bit sign extend of that 32 bit constant. That would be a stupid choice for an assembler designer. An assembler constant does not inherently have a size. So 0xFFFFFFFF in 64 bit assembler ought to mean 4294967295 and ought not to mean -1.

Whatever that instruction does or should mean, it seems to be a rotten way to accomplish whatever it is supposed to accomplish. But I don't understand enough of the OP's posts or knudfl's plausible looking reply to put any of that in real context.

Can you explain that? Is the "bad" assembler instruction generated by some part of binutils (maybe from C code in the grub sources)? I would have guessed that instruction was more directly from the grub sources.

Or do you mean you think that assembler line isn't bad and/or some version of as will interpret it as meaning
AND $-1, %rsi

I'm also confused by your and knudfl's mention of "32bits Slackware" when discussing an assembler instruction that uses a 64 bit general register.

Are we talking about a 32 bit assembler in which %rsi is not valid as any operand of any instruction? Or are we talking about a 64 bit assembler in which 0xFFFFFFFF should not be valid as the source operand of an AND instruction?

Hi there,

thanks for the information - up to now I only knew the Intel syntax (I grew up with TASM & MASM).

Since I didn't know what %RSI was supposed to mean, I guessed it was the "strange" form for "register SI". And I've never programmed 64bit code, so I didn't know about the special meaning of RSI. By the way, what does the 'R' literally stand for?

[X] Doc CPU

I think it stands for... register .
From http://www.x86-64.org/documentation/assembly.html. So the r is just to match the new registers.