[ASM] a problem with shl and nasm

[Caleb1994]

I am trying to shift a number in AX by a value stored at [ds:218h], but I keep getting an "invalid combination of opcode and operands" error. For the life of me, I can't figure out what the type of the second parameter should be. It works with constant values, so this works:

shl ax,4

but with registers, and memory locations it doesn't. Both of these cause the above error:

shl ax,bl
shl ax,byte[ds:218h]

Also, in an attempt to figure out the type that this should be, I tried the following:

shl ax,byte[4]
shl ax,word[4]
shl ax,dword[4]

All of them had the same effect as using a register, which doesn't make any sense. Those are the only three types it can be, unless i'm misusing the byte[],word[],dword[] operators. Which is very possible. I am just dabbling with boot loaders and such, and don't have tons of experience in assembly.

I would assume the value should be 8bit since ax is 16bit, which means there are only 16 needed values for the second parameter.

if someone could shoot me a link to the shl command specs, or lemme know what i'm doing wrong (probably multiple things ) that would be great, thanks.

[azblue]

I don't think you can shift by a variable. Other than a constant, I think the only thing you can shift by is cl. So load the cl register with your variable first and then use it to shift.

[Love4Boobies]

Move the value into CL and then shift by that. Also, RTFM (in this case, the Intel manuals, particularly volume 2B).

[Caleb1994]

Alright. Thanks guys!

That's odd that you can only shift by CL/constant. Is that arbitrary or is there a reason?

[Love4Boobies]

The 8086 had quite few transistors, as is reflected by not only its limited functionality, but also several instructions which couldn't be implemented in a whole lot of ways. Eventually, some were extended (e.g., IMUL was initially as sucky as MUL but was extended with the 80286 when more transistors were added).

Nowadays, transistors are not a problem anymore. However, we now face a new problem: there's a limited amount of ways in which instructions can be encoded efficiently (you don't want the CPU to spend time decoding an 128-byte instruction, do you)? Hence, it doesn't make sense to extend all instructions. In fact, some are completely dropped in x86-64's long mode (but not compatibility mode) in favour of new ones.

I'm surprised you didn't ask this question when you first started using instructions like MUL and DIV...

[Caleb1994]

Nowadays, transistors are not a problem anymore. However, we now face a new problem: there's a limited amount of ways in which instructions can be encoded efficiently (you don't want the CPU to spend time decoding an 128-byte instruction, do you)? Hence, it doesn't make sense to extend all instructions. In fact, some are completely dropped in x86-64's long mode (but not compatibility mode) in favour of new ones.

Oh alright. I guess that makes sense. Just wondering.

I'm surprised you didn't ask this question when you first started using instructions like MUL and DIV...

I did wonder about the implementation, but never felt a need to bother a forum with it, since I understood how to call them, and beyond that it was just extra information.

Although it is nice to know why now! lol