Assembly Language Help ;)

This is a discussion on Assembly Language Help ;) within the C++ Programming forums, part of the General Programming Boards category; >> "Only executed once during boot up" Are you trying to use new and stdio from within a kernel/other standalone? ...

  1. #16
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    >> "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).
    Last edited by User Name:; 03-08-2011 at 07:40 PM.

  2. #17
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    Quote Originally Posted by shrink_tubing View Post
    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:

    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:
    You don't need to use new here.

  3. #18
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by User Name: View Post
    >> "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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #19
    Registered User
    Join Date
    Jan 2010
    Posts
    87
    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

  5. #20
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by shrink_tubing View Post
    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].
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,249
    Quote Originally Posted by Elysia View Post
    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?
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #22
    Registered User
    Join Date
    Jan 2010
    Posts
    87
    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

  8. #23
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,788
    Quote Originally Posted by shrink_tubing View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    Registered User
    Join Date
    Jan 2010
    Posts
    87
    Thanks

  10. #25
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    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.
    Last edited by VirtualAce; 03-10-2011 at 11:53 PM.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Assembly language.
    By JOZZY& Wakko in forum Tech Board
    Replies: 0
    Last Post: 12-18-2009, 04:58 AM
  2. Why C Matters
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 136
    Last Post: 01-16-2008, 08:09 AM
  3. Assembly Language Forums??
    By gqchynaboy in forum Tech Board
    Replies: 3
    Last Post: 11-22-2004, 05:59 AM
  4. Language Script..
    By vasanth in forum A Brief History of Cprogramming.com
    Replies: 12
    Last Post: 03-30-2003, 05:48 AM
  5. help in assembly language
    By ema in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 12-14-2002, 01:22 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21