type dword and assembly

[juliomacedo]

When I write something as

Code Select Expand

mov( eax, (type dword x));

I'm writing HLA but not "pure" Assembly.... How is the processor instruction behind this kind of code? This way?

Code Select Expand

mov( eax, x);

Writing "type dword x" instead of simply wrtiting "x" is just something that we do because of some HLA type checking or it means somenting different in the final assembly instruction?

Thanks

Julio

[zooba]

I'm not very familiar with HLA, but in MASM 'DWORD PTR' (equivalent to 'type dword') is not necessary because the use of EAX implies that X is 32-bits.

However, the final instruction is different depending on the size of the data you are moving. The assembler takes care of the details but if it has no way of figuring out what you mean (eg. mov [esi], 0) it will require you to specify a type.

Since X is just a label (an address), it is possible to refer to either the BYTE, WORD, DWORD or something else at that address. If it has been defined as a DWORD then by default the assembler will assume it's a DWORD. However, as I said, since the registers are known sizes the 'TYPE DWORD' should be unnecessary.

[juliomacedo]

In this case, x was defined as an int64 variable...

Since x is just an address (as you said), it seems not important to "convert" to dword, excpet for assembler type checking...

[Randall Hyde]

When I write something as

Code Select Expand

mov( eax, (type dword x));

I'm writing HLA but not "pure" Assembly.... How is the processor instruction behind this kind of code? This way?

???
You *are* writing "pure" assembly. All you're doing here is telling HLA to treat x as a dword object rather than as it's declared type. This is semantically equivalent to

Code Select Expand


mov dword ptr x, eax

in MASM.

There is nothing "unpure" about this. "Pure assembly" refers to using only low-level machine instructions, versus using HLL-like control structures like IF, WHILE, FOR, etc.

Code Select Expand

mov( eax, x);

Writing "type dword x" instead of simply wrtiting "x" is just something that we do because of some HLA type checking or it means somenting different in the final assembly instruction?

Thanks

Julio

Yes, writing "(type dword x)" simply overrides the default type for memory location x (I'm assuming it was declared as byte, word, qword, or some other non-dword type). Again, type checking is *standard* in x86 assembly language (e.g., Intel Syntax). Some assemblers dropped this, but that was a choice by those assembler authors and really has nothing to do with whether the source is "pure" assembly. Type checking has been present in x86 assembly since the very first Intel assembler.
Cheers,
Randy Hyde

[juliomacedo]

I thought for a moment that this instruction would me translated into more than one instruction that's why I thought about "pure" assembly...

For example, I don't like using mov(mem, mem) since this is not a real cpu instruction. I know it's a "gift" HLA give us but it may cause problems on my mind later when I try to use MASM or other assembler...

As type dword x is just a matter of type checking, teher's no problem in using it.

Thanks

[Randall Hyde]

I thought for a moment that this instruction would me translated into more than one instruction that's why I thought about "pure" assembly...

For example, I don't like using mov(mem, mem) since this is not a real cpu instruction. I know it's a "gift" HLA give us but it may cause problems on my mind later when I try to use MASM or other assembler...

Indeed, and it is a "broken" gift (no eight-bit moves). I'm probably going to remove it from HLA v2.0 because, unlike the HLL control structures, it *looks* like a low-level machine instruction and people use it without realizing they are not writing assembly code.  This will break some code (including mine), but people who want to continue using it can easily write a macro to do the job for them.

Cheers,
Randy Hyde

[juliomacedo]

it *looks* like a low-level machine instruction and people use it without realizing they are not writing assembly code. This will break some code (including mine), but people who want to continue using it can easily write a macro to do the job for them.

I agree with you...

[Sevag.K]

I thought for a moment that this instruction would me translated into more than one instruction that's why I thought about "pure" assembly...

For example, I don't like using mov(mem, mem) since this is not a real cpu instruction. I know it's a "gift" HLA give us but it may cause problems on my mind later when I try to use MASM or other assembler...

Indeed, and it is a "broken" gift (no eight-bit moves). I'm probably going to remove it from HLA v2.0 because, unlike the HLL control structures, it *looks* like a low-level machine instruction and people use it without realizing they are not writing assembly code.  This will break some code (including mine), but people who want to continue using it can easily write a macro to do the job for them.

Cheers,
Randy Hyde

Are you gong to cancel all the HLA 'helper' instructions?

[Randall Hyde]

I thought for a moment that this instruction would me translated into more than one instruction that's why I thought about "pure" assembly...

For example, I don't like using mov(mem, mem) since this is not a real cpu instruction. I know it's a "gift" HLA give us but it may cause problems on my mind later when I try to use MASM or other assembler...

Indeed, and it is a "broken" gift (no eight-bit moves). I'm probably going to remove it from HLA v2.0 because, unlike the HLL control structures, it *looks* like a low-level machine instruction and people use it without realizing they are not writing assembly code.  This will break some code (including mine), but people who want to continue using it can easily write a macro to do the job for them.

Cheers,
Randy Hyde

Are you gong to cancel all the HLA 'helper' instructions?

MOV is going away because of the inconsistencies assocated with 16/32 vs 8-bit moves.
I'd thought I'd already eliminated all the other "pseudo-machine" instructions in earlier versions of HLA v1.x. Which "helper" instructions am I missing?
Cheers,
Randy Hyde

[Sevag.K]

MOV is going away because of the inconsistencies assocated with 16/32 vs 8-bit moves.
I'd thought I'd already eliminated all the other "pseudo-machine" instructions in earlier versions of HLA v1.x. Which "helper" instructions am I missing?
Cheers,
Randy Hyde

I mean the instructions that simulate 'extensions' to the x86 instructions; mul, imul, div, idiv, mod, imod and anything else I've missed.

[Randall Hyde]

MOV is going away because of the inconsistencies assocated with 16/32 vs 8-bit moves.
I'd thought I'd already eliminated all the other "pseudo-machine" instructions in earlier versions of HLA v1.x. Which "helper" instructions am I missing?
Cheers,
Randy Hyde

I mean the instructions that simulate 'extensions' to the x86 instructions; mul, imul, div, idiv, mod, imod and anything else I've missed.

Ah yes, forgot about mod. Nope, it's staying. As are the constant operands for those instructions.
Cheers,
Randy Hyde