ASM to C language

I am hoping someone could shed some light on a possible ASM to C language translation of some ASM code.
OK, first off let me say that I know basically nothing about C language programming, or any language programming for that matter.
This little chunk of ASM code has been bothering me in regard to a C language translation.

mov eax, [eax - 33] ; mov data from somewhere to eax
cdq ; convert double to quad
shl edx, 8 ; shift left edx c << 8;
sbb eax, edx ; subtract with borrow
sar eax 8 ; shift right eax c >> 8;

I know the translation between ASM and C isn't nessarily easy, but it seems a lot of the ASM instructions can be generalized in some type of C expression I guess. What confuses me about the ASM code I posted is the cdq, sbb instructions, and in this case the use of cdq when it's not followed by idiv.

x86 instruction listings - Wikipedia, the free encyclopedia

Quote:

---

Sign-extends EAX into EDX, forming the quad-word EDX:EAX. Since (I)DIV uses EDX:EAX as its input, CDQ must be called after setting EAX if EDX is not manually initialized (as in 64/32 division) before (I)DIV.

---

Basically, EDX becomes 0x00000000 or 0xFFFFFFFF depending on the sign of EAX

Basically, in a compiler that supports 64-bit operations, this should do it:

Code:

---

int x = somewhere;
int64 y = x << 8;

---

--
Mats

I know that the code I posted is 32-bit (Watcom 9.01d), so I'd assume 64-bit operations are out of the question since this version of Watcom doesn't support "long long". I keep reading about "sign-extends" in regard to a cdq ASM operation, but for some reason I just can't grasp the concept......In the case of modulus "%" I understand, but not when there's cdq NOT followed by idiv. So, how would one sign-extends eax into edx when no division is to take place in 32-bit mode in C language?

Sign extension has nothing whatsoever to do with division? Sign extension just says "I need more bits: if the number is positive, make them 0; if the number is negative, make them 1." (The point being, doing it that way keeps the value of the number the same, even with the extra bits, assuming general 2's complement notation.)

So, you want to do the same thing in a different compiler, or are you using Watcom 9.x? If you use a modern compiler, it should work to just use a 64-bit int. it gets rather complicated to do this with only 32-bit C code.

Sign extension is when you take a small integer - to make it simple, short converted to int:
16 bits of signed data (short) need to be made into 32-bits of signed form. That means that anything from 0x0000 to 0x7FFF becomes 0x00000000 to 0x00007FFFF, and 0x8000 to 0xFFFF becomes 0xFFFF8000 to 0xFFFFFFFFF. The principle being that the SIGN bit (15th bit in a 16-bit number) is filled into the rest of the number. Same obviously applies for 32-bit to 64-bit or 64-bit to 128-bit signed numbers [and 8-bit to 16-/32-bit integers, e.g. a signed form of char to short or integer].

--
Mats

I'm actually using the same compiler Watcom 9.01d. So, lets say the integer is 8074 (int a = 8074). Since the compiler only supports up to 32-bit operations should I assume "int a;" is a short?

mov eax, [eax - 33] ; mov 8074 (hex 0x00001F8A) into eax

now what happens???

Why do you need to:
1. Use Watcom compiler - there are several other compilers that are a few years less than 14 years old - old age is NOT an advantage in compilers?
2. Translate this FROM assembler?

--
Mats

Quote:

---

Originally Posted by tabstop

Sign extension has nothing whatsoever to do with division? Sign extension just says "I need more bits: if the number is positive, make them 0; if the number is negative, make them 1." (The point being, doing it that way keeps the value of the number the same, even with the extra bits, assuming general 2's complement notation.)

---

Yes, but the most common reason this is done is in preparation for a 32-bit division operation. On x86, you can divide a 64-bit quantity by a 32-bit quantity, or a 32-bit quantity by a 16-bit quantity. But in C, you commonly divide two 32-bit quantities, so the numerator first has to been sign-extended in order to allow the division by a 32-bit denominator

OK, short version of a long story:
I recently fired up an old computer (Windows 95 updated to Window 98 first edition) and while browsing through some of my old files I came across this stuff I must have been working on at one time. So, some 11 years later this "unfinished" stuff has recaptured my attention for no other reason than to solve the this puzzle. The reason why I'm using Watcom 9.01d is because that's what's on the old computer.

So, that explains why you are using an ancient computer. Not why you need to translate this to C!

--
Mats

Quote:

---

Yes, but the most common reason this is done is in preparation for a 32-bit division operation. On x86, you can divide a 64-bit quantity by a 32-bit quantity, or a 32-bit quantity by a 16-bit quantity. But in C, you commonly divide two 32-bit quantities, so the numerator first has to been sign-extended in order to allow the division by a 32-bit denominator

---

This is one reason why I'm confused with the cdq operation in the ASM code I posted since there is 32-bit division following the cdq......Rather, you find a shift left instead.

Doesn't Watcom C support __int64? If not, then see if it has stdint.h and look for int64_t

But cdq is not DIRECTLY related to divide instructions - it's simply OFTEN used together with divide instructions, because to get a 32-bit result in divide, you need a 64-bit input [that's just the way the processor is designed].

And by the way, I'm not sure I'm right on the analysis of what the code does. I think it's actually a divide by 256 and modulo 256 "in one".

So resembling the normal divide instruciton, but using much faster shift instructions instead.

--
Mats

Quote:

---

So, that explains why you are using an ancient computer. Not why you need to translate this to C!

---

The ASM code was from a program written in C language......I retrieved the ASM code via SoftIce when I was messing around with trying to write an ADS application for a program. The retrieved ASM code was to be the outline for what I was going write in the application. Anyhow, in the notes I left there was this confusion surrounding three of the lines of ASM code which I posted initially.

cdq
shl edx, 8
sbb eax, edx

I went on to write (in my notes) that the ASM code basically did nothing and was not needed in the application I was writting. Now, some 11 years later it still nags me that I couldn't translate these three operations to C language.

Quote:

---

Doesn't Watcom C support __int64? If not, then see if it has stdint.h and look for int64_t

---

There is no stdint.h file with Watcom 9.01d.

Watcom C compiler - Wikipedia, the free encyclopedia says that the version 11 added 64-bit support.

--
Mats

So far as I can tell it's more like (x/256) rounded toward zero.

More specifically: the extension makes edx all 1 or all 0; the shl will put eight zeros at the end and set the carry bit where appropriate; the sbb will either do nothing (if eax was positive) or, if eax was negative will give the same exact upper eight bits only if the lower eight bits are all zero, otherwise it will be one more than that. [For instance, -512 gives -512(+ stuff in the lower eight bits) because of the carry bit, but -511 gives -256(+ stuff).] The shr then cuts out the last eight bits, doing the division.

Quote:

---

So far as I can tell it's more like (x/256) rounded toward zero.

More specifically: the extension makes edx all 1 or all 0; the shl will put eight zeros at the end and set the carry bit where appropriate; the sbb will either do nothing (if eax was positive) or, if eax was negative will give the same exact upper eight bits only if the lower eight bits are all zero, otherwise it will be one more than that. [For instance, -512 gives -512(+ stuff in the lower eight bits) because of the carry bit, but -511 gives -256(+ stuff).] The shr then cuts out the last eight bits, doing the division.

---

You totally lost me!!! Any way to break it down to more "simple" term that a novice might understand?

OK, i tried the following piece of code:

Code:

---

y = x/256;
y <<= 8;
x -= y;

---

And it actually produced the ASM code:
cdq
shl edx 8
sbb eax, edx

Now comes the important question.....Since all this piece of code seems to do is clear edx, what's the purpose of it? Could it actually be used as an error check of some kind or something?

Actually, just using
y = x/256;
yields the three ASM operations (cdq, shl, sbb). But the question still remains as to it's purpose other than clearing edx??????

Quote:

---

Originally Posted by TAZIN

Actually, just using
y = x/256;
yields the three ASM operations (cdq, shl, sbb). But the question still remains as to it's purpose other than clearing edx??????

---

The purpose of what?

The purpose of the whole thing is to give you x/256, as you mentioned. That's what's left in eax when all is said and done, is x/256. edx gets set to something in the meantime, but that's just extra scratch work that needs to be done in order to compute the answer.

Quote:

---

The purpose of the whole thing is to give you x/256, as you mentioned. That's what's left in eax when all is said and done, is x/256. edx gets set to something in the meantime, but that's just extra scratch work that needs to be done in order to compute the answer.

---

I understand now. Thanks to all who contributed to this thread.