Assembly Language Help ;)

Hi,

I'm running some simple assembler code to try and get the details of the CPU. I'm compiling using Code::Blocks so here is the code ;)

Code:

---

#include <iostream>

int main()
{
    int i = 0;

    char* ptr1 = new char[4];

    std::cout << ptr1 << std::endl;

    asm("movl %1, %%eax; CPUID; movl %%ebx, %0;"
        :"=r"(ptr1)  // output %0
        :"r"(i)  // input %1
        :"%eax","%ebx");

    std::cout << ptr1[0] << std::endl;

    return 1;
}

---

Ok but I'm having some problems. As far as I understand it, the CPUID instruction causes data to be written into the registers ebx,ecx and edx. Ok great 4 bytes a piece. So I made a char array which can hold 4 chars, 1 byte each. I move the int 0 into eax and then commence the instruction and then move the first 4 bytes coming from ebx to the pointer variable.

I'm doing something wrong here though. I get the feeling this is too simplified, but I really don't know how to progress. Can anyone offer any insight here? Many thanks ;)

You don't need to use new here.
Furthermore, your code is leaking memory, again a reason not to use new.

Bad assembly! The standard says that 'ebx' must remain the same.

Code:

---

"push %%ebx;"
.....
"pop  %%ebx;"

---

EDIT: Not to mention that you pass ptr1 as register. Do you expect that GCC's gonna guess you're passing a pointer? Think again! 'ebx' is passed to 'ptr1', not '*ptr1' !

What standard?

Quote:

---

Originally Posted by Elysia

What standard?

---

Sorry, wrong word. There's no actual standard, but i've read it here.

Ah, I see. You just need to remember that calling conventions as they're called is not standard. They vary from compiler to compiler (and platform to platform).
So basically you have to be aware of the calling convention used by your platform/compiler to write good assembly.

Thanks for the replies. I'll go and fix the memory leak, this code is, as I already know really, total cr@p at the moment :D

I wasn't even aware of any special instructions concerning pointers, I think I need to investigate push and pop ;)

I thought that given that the register can hold a 32 bit value - 4 bytes and a char is 8 bits - 1 byte I might be ok trying to copy the contents of the register to a variable which is initialised to point to a place with 4 bytes of memory allocated.

Maybe that is indeed a correct assumption but I'm obviously not using proper syntax here. Exactly what would I need to do to get those 4 bytes from ebx into the address pointed to by the variable ptr1?

Thanks :)

Quote:

---

Originally Posted by shrink_tubing

Exactly what would I need to do to get those 4 bytes from ebx into the address pointed to by the variable ptr1?

---

"=p" instead of "=r" ( The easy work-around )

Thanks for everyone's help! I finally got it to work after alot of reading. Here is a very inefficient but working version:

Code:

---

#include <iostream>
#include <stdio.h>

int main()
{
    char* ptr1 = new char[4];
    char* ptr2 = new char[4];
    char* ptr3 = new char[4];

    asm("movl %0, %%esi; movl $0, %%eax; CPUID; movl %%ebx, (%%esi);"
        :
        :"m"(ptr1)
        :"memory","%eax","%ebx","%esi");

    asm("movl %0, %%esi; movl $0, %%eax; CPUID; movl %%edx, (%%esi);"
        :
        :"m"(ptr2)
        :"memory","%eax","%edx","%esi");

    asm("movl %0, %%esi; movl $0, %%eax; CPUID; movl %%ecx, (%%esi);"
        :
        :"m"(ptr3)
        :"memory","%eax","%ecx","%esi");

    for(int i = 0; i < 4; i++)
    {
        printf("%c",ptr1[i]);
    }

    for(int i = 0; i < 4; i++)
    {
        printf("%c",ptr2[i]);
    }

    for(int i = 0; i < 4; i++)
    {
        printf("%c",ptr3[i]);
    }

    delete ptr1;
    delete ptr2;
    delete ptr3;

    return 1;
}

---

This will print the 12 character name of the processor to the screen using AT&T syntax as used in the Code:Blocks compiler which I believe is of type GCC ;)

Here's a much neater, nicer version:

Code:

---

#include <stdio.h>

int main()
{
    char* ptr = new char[12];

    asm("movl %0, %%esi;"
        "movl $0, %%eax;"
        "CPUID;"
        "movl %%ebx, (%%esi);"
        "movl %%edx, 4(%%esi);"
        "movl %%ecx, 8(%%esi);"
        :
        :"m"(ptr)
        :"memory","%eax","%esi");

    for(int i = 0; i < 12; i++)
    {
        printf("%c",ptr[i]);
    }

    delete ptr;

    return 1;
}

---

I'm not sure if I should have registers ebx,ecx and edx on the clobber list though. DO I need to do that or will the instruction CPUID automatically inform the machine that the registers ebx,ecx and edx have been written to and it can no longer depend on those values being as they were before the CPUID instruction was run?

doesn't gcc preserve registers for you if you list them in the clobber list?

Quote:

---

Originally Posted by Elkvis

doesn't gcc preserve registers for you if you list them in the clobber list?

---

Yes, i forgot.

Well although it may be inefficient I am going to add all affected registers to the clobber list, just to make sure. This code only executes once during boot up so it's ok from that persepctive. I would imagine it isn't guaranteed that CPUID will inform GCC that registers ebx,ecx and edx are affected which may screw something up in the future if it expects to find a certain variable in a register such as say ebx only to find a 4 byte string ;o)

Thanks for the help anyway ;)

The code is still even worse now. You turned code with memory leaks into code with undefined behavior.
Why are you using new in the first place? Get rid of it!

Quote:

---

Originally Posted by Elysia

The code is still even worse now. You turned code with memory leaks into code with undefined behavior.
Why are you using new in the first place? Get rid of it!

---

Your 17000+ posts suggests to me you know a thing or two about programing. I'd be interested to know why the code has undefined behaviour as I honestly can't see it - which means I'm missing something. I know you're right, I just don't know why. What would I need to do to correct this?

>> "Only executed once during boot up"
Are you trying to use new and stdio from within a kernel/other standalone?

I think Elysia is referring to the fact you left eax, ebx, ecx, and edx off your clobber list, and therefore your compiler is completely unaware of the fact you modified them(possibly trashing stuff put there by the compiler, without its knowledge).

Quote:

---

Originally Posted by shrink_tubing

Your 17000+ posts suggests to me you know a thing or two about programing.

---

Prolixity is an indication of free time, not knowledge. Especially when about half of those come from circular debates from ever changing positions about whether scrambled eggs are better for you than poached eggs or something equally as pointless. That said:

Quote:

---

I'd be interested to know why the code has undefined behaviour

---

Code:

---

char* ptr = new char[12]; // here be square brackets

delete ptr; // here be no square brackets

---

Do yourself a favour and heed this:

Quote:

---

You don't need to use new here.

---

Quote:

---

Originally Posted by User Name:

>> "Only executed once during boot up"
Are you trying to use new and stdio from within a kernel/other standalone?

I think Elysia is referring to the fact you left eax, ebx, ecx, and edx off your clobber list, and therefore your compiler is completely unaware of the fact you modified them(possibly trashing stuff put there by the compiler, without its knowledge).

---

You are potentially always invoking undefined behavior when using inline assembly because the standard cannot guarantee it will work.
That said, this is something you should be aware of when you invoke inline assembly. It's a decision you make knowingly.
No, it is the fact that new [] needs delete []. The reason I didn't point it out is because I didn't want to defer from the fact that there was no need for new in the first place.

Well I think this is all very good advice.

With regards the new thing a few questions:

1) When calling delete[] after a call to new[] I assume the code first goes to the address the pointer is pointing to and then deletes and initialises the amount of memory specified to delete between the two [] brackets. Then I assume it deletes the pointer itself - which I believe is 4 bytes long. IS this correct?

2) Given that the pointer here is pointing to char, I assume the code then reads the [12] part as 'I must clean out 12 bytes worth of memory' given that a char is 1 byte (8 bits, 0 - 255 characters codes). If it was pointing to say an integer, which I believe is 4 bytes long, then would the code interpret delete[12] as 'I must goto this memory address and delete 12*4 = 48 bytes of memory'? Is that how it works?

So I imagine from this then that just calling delete and not delete[12] leaves about - in the char example - 12 bytes of garbage residing in memory which the computer assumes is initialised - when it is anything but. This I guess is the undefined behaviour?

I'd appreciate some help here even if it's just to confirm where I'm right ;)

Thanks :D

Quote:

---

Originally Posted by shrink_tubing

1) When calling delete[] after a call to new[] I assume the code first goes to the address the pointer is pointing to and then deletes and initialises the amount of memory specified to delete between the two [] brackets. Then I assume it deletes the pointer itself - which I believe is 4 bytes long. IS this correct?

---

No, no, no.
First of all, you specify no size when calling delete. You leave the brackets empty.
When you delete some newed memory, the entire memory you allocated via new is deleted. The memory is not "initialized." It is simply returned to the operating system.
The pointer itself is not deleted--it cannot possibly be, since it is a variable on the stack.

Quote:

---

2) Given that the pointer here is pointing to char, I assume the code then reads the [12] part as 'I must clean out 12 bytes worth of memory' given that a char is 1 byte (8 bits, 0 - 255 characters codes). If it was pointing to say an integer, which I believe is 4 bytes long, then would the code interpret delete[12] as 'I must goto this memory address and delete 12*4 = 48 bytes of memory'? Is that how it works?

---

No. You have a block of memory allocated, and that is all. So when you delete, you free that block. We don't need to know the size of the block, because the entire block is freed, not some individual elements inside the block. It's all or nothing.

Quote:

---

So I imagine from this then that just calling delete and not delete[12] leaves about - in the char example - 12 bytes of garbage residing in memory which the computer assumes is initialised - when it is anything but. This I guess is the undefined behaviour?

---

We cannot predict what will happen exactly. That is why it's undefined. And it's still delete [] and not delete [12].

Quote:

---

Originally Posted by Elysia

We cannot predict what will happen exactly. That is why it's undefined. And it's still delete [] and not delete [12].

---

I can predict it...

Nothing bad will happen. char is POD with no destructor. The reason delete and delete[] are different is knowing how to invoke all the destructors on an array of objects. These objects have no destructors.

It's strictly wrong, but in practice will never cause a problem. Worrying about standards-conformance in a function using compiler-specific-architecture-specific inline assembly is kind of silly. I do agree that the dynamic allocation is pointless in the first place -- why not just declare a 32-bit integer and use that?

That's great thanks. So out of curiousity could I have just declared a pointer to char and then used the assembly movl command to send the 32 bits of information there, without buggering something in memory? Do I not have to have 32 bits of memory - I don't know - cleared or reserved in some way?

I can see how the integer thing would have worked but then I'd have had to read it back byte by byte as 4 chars. I wouldn't really know how to do this, and it's not how the book's author does it, and he's a professional so he's above any questioning from me. He uses just a pointer to char as far as I remember.

If I can understand this last concept then I can move on from this topic and start working on getting that assembler code file compiled using AT&T syntax rather than intel - which for me will be a very big achievement ;)

Cheers for all the help so far,

Chris :)

Quote:

---

Originally Posted by shrink_tubing

That's great thanks. So out of curiousity could I have just declared a pointer to char and then used the assembly movl command to send the 32 bits of information there, without buggering something in memory?

---

No.
If you declared an int or a char array of 4 elements, then yes, it should be possible.

Quote:

---

Do I not have to have 32 bits of memory - I don't know - cleared or reserved in some way?

---

Yes.

Quote:

---

I can see how the integer thing would have worked but then I'd have had to read it back byte by byte as 4 chars.

---

No.
Provided enough storage, you can easily move n bytes at a time, where n is any number of bytes supported by the cpu. Typically 4 or 8.

Quote:

---

I wouldn't really know how to do this, and it's not how the book's author does it, and he's a professional so he's above any questioning from me. He uses just a pointer to char as far as I remember.

---

Really? I have a hard time figuring that since "he" uses new and forgets to delete.

Quote:

---

If I can understand this last concept then I can move on from this topic and start working on getting that assembler code file compiled using AT&T syntax rather than intel - which for me will be a very big achievement ;)

---

You are using AT&T syntax.

Thanks ;)

Quote:

---

think Elysia is referring to the fact you left eax, ebx, ecx, and edx off your clobber list, and therefore your compiler is completely unaware of the fact you modified them(possibly trashing stuff put there by the compiler, without its knowledge).

---

I could be wrong here but no code should ever expect the values in the explicit return registers to hold anything meaningful across a function call and therefore it is pointless to put them in the clobber list. No compiler in its right mind would ever stick a value in one of these registers and then rely on it when coming back from an inline assembly section. Assembly programmers are not supposed to rely on explicit return register values across function calls and if they must then they should push the values to the stack prior to making a call to another function and then pop them back off the stack into the register after the call.

If I recall the clobber list is GCC's optimized way of allowing inline assembly without forcing a pushf and a complete save of the registers prior to inline assembly and a popf and restore of the registers after the inline assembly. Microsoft compilers have no such constructs and therefore the compiler must preserve the registers before the call and restore them after the call. I'm not sure if it saves the explicit return value registers or not.