Thread: Assembly Language Help ;)

>> "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).

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.

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.

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.

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].

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?

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.

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

Yes.

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.

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.

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.

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.