I Have A Question About Pointers

[davidthefat]

Now this is where I have not been able to wrap my head around: do pointers take up space in the memory heap? I know that pointers just reference to a specific memory "slot", but is it a "physical" object in the memory that takes up space? Or is it just what the compiler sees and uses to get the data that the pointer references to? Also does this mean an array is also like a pointer, just references to multiple objects? I am not sure if I am asking the questions right.

I have been using C++ for years and I have not thought about this until recently. I just assumed pointers were just an object that references to an objects location; are they like "#define"s where only the compiler uses value?

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
using namespace std;
/*
+---+--------------------+
| r |    Register(s)     |
+---+--------------------+
| a |   %eax, %ax, %al   |
| b |   %ebx, %bx, %bl   |
| c |   %ecx, %cx, %cl   |
| d |   %edx, %dx, %dl   |
| S |   %esi, %si        |
| D |   %edi, %di        |
+---+--------------------+
*/
uint16_t assemblyAddition(uint16_t input1, uint16_t input2);

int main()
{
    uint16_t *input1;//This should not take up any space in memory right?
    input1 = (uint16_t*)calloc(2, sizeof(uint16_t));//This allocates a piece of memory for 2 shorts (16 bits * 2 == 32 bits) and initializes it. 
    //Now the pointer points to that memory region
    if(input1 == NULL)
    {
        cout << "YOU DUN GOOFD!";
        return 1;
    }
    input1[0] = 0x0;//This sets the referenced object (that was allocated above) to 0
    input1[1] = 0x0;
    cout << "Number 1: ";
    cin >> input1[0];
    cout << endl << "Number 2: ";
    cin >> input1[1];
    cout << endl <<"Result : " << assemblyAddition(input1[0], input1[1]) << endl;
    free(input1);//This allows the allocated memory to be used again, but does it set everything to 0?
    return 0;
}

uint16_t assemblyAddition(uint16_t input1, uint16_t input2)
{
    uint16_t result = 0x0;
    asm("addw %%bx, %%ax;" : "=a"(result) : "a" (input1), "b" (input2));
    return result;
}

edit: since pointers have a datatype, does it take up as much space as the datatype (for my example, 32 bits? 16 * 2 == 32)
I thought they just stored the memory slot number, so I am just confusing myself.

[EricVanWyk]

A pointer takes up space in its own right, usually 32 or 64 bits depending on the memory map. It isn't just a compiler construct - it gets used at run time. This lets you do pointer arithmetic.

[davidthefat]

Originally Posted by EricVanWyk

A pointer takes up space in its own right, usually 32 or 64 bits depending on the memory map. It isn't just a compiler construct - it gets used at run time. This lets you do pointer arithmetic.

So my example uses 64 bits of memory from just the variables? 32 from the pointer it self, 16 from short, and another 16 from the other short. I don't know how much the streams use up.

[mikets]

If it is a variable, it takes up space in memory. A char variable takes 1 byte, a short variable takes 2 bytes, a long variable takes 4 bytes, an int on a 32-bit machine takes 4 bytes. A pointer variable on a 32-bit machine also takes 4 bytes.

int A = 40;
long B = 50;
int *ptrToA = &A;
long *ptrToB = &B;
 
addr           value      variable name
====           =====      =============
        +----------------+
1000    |       40       |  A
        +----------------+
1004    |       50       |  B
        +----------------+
1008    |      1000      |  ptrToA
        +----------------+
1012    |      1004      |  ptrToB
        +----------------+
        |      ....      |

[davidthefat]

So the cRio has 32 General Purpose Registers and 32 Floating Point registers? Since cRio apparently has a PPC core.

On the other hand, I am impressed that the mars rovers used VxWorks as their OS.

Does the cRio have a 64 bit structure?

So if a pointer does take up that much space, it seems like a structure would be more efficient for variables under 32 bits than using singletons.

[Greg McKaskle]

Predicting how much memory is used for a given bit of code requires quite a bit of knowledge about the machine architecture. One of the most common tradeoffs in electronics and computer is "space for speed". This is true in your code, but often true in the computer architecture itself.

As an example of this, how much space is taken by
struct { int8 a; int16 b; }[1000]?

The naive answer is (1+2)*1000, but on many architectures, alignment rules force the int16 to be on a two byte alignment and for the struct to actually take four bytes. Additionally, when you malloc you'll find both internal and external fragmentation. You will often find memory managers making all sorts of tricks to avoid locks, to speed up contention for the free list, etc.

Additionally, while a pointer represents space, if they are in a local scope they may actually be just a register and use no memory. This is also true of ints, floats, and any local of sufficiently small scope.

For future reference, if you use sizeof(int*) or any other type, that is a good estimate for memory usage, but all of the factors listed above and many more make an impact.

Greg McKaskle

[wireties]

In your example input1 DOES take up space in memory (whether or not you call the calloc), 4 bytes on the stack of the vxWorks task in which it executes. After the calloc call, input1 contains an address that points to a location in the heap. The space used in the heap is probably 4 bytes but could be more. For example vxWorks has an option to insert boundaries around heap allocations (where it inserts a certain pattern) to assist in memory analysis. Greg's observations about alignment also play a role.

The data type referred to by the pointer does NOT changed the amount of memory the pointer itself consumes. But it does determine how pointer arithmetic increments/decrements. For your example, input1++ increases the address pointed to by 4 bytes. If input1 were declared to pointer to a double, it would increase by 8 bytes and so on.

I think our version of the PowerPC is a 32-bit machine thus integers and pointers are 4-bytes.

HTH

[davidthefat]

Oh man, I have been reading this assembly book. EVERYTHING makes so much more sense to me now.

[davidthefat]

Is it safe to assume that it runs in protected mode? Sorry for the double post, but I can't edit my latest post. Now is anyone else thinking of writing the code for next year in assembly? Obviously not the whole thing, but some of the calculations and stuff like that would not be too bad. Well, if you are already doing pointer arithmetics, it can be replaced with assembly code.

[mikets]

Are you talking about the PowerPC processor in the cRIO or are you talking about Intel processor? Your initial post listed all the Intel processor registers. So I am not sure which one you are asking?

[demosthenes2k8]

I'm sorry, but you appear to have a need to overcomplicate everything. If there's really no need to write the code in assembly, it would probably be better to write it in C++, because the compiler can probably write better assembly than a human.

[davidthefat]

Originally Posted by mikets

Are you talking about the PowerPC processor in the cRIO or are you talking about Intel processor? Your initial post listed all the Intel processor registers. So I am not sure which one you are asking?

That is true, that was written for my computer, the thread started out as a general question and is becoming more specific. I know the PPC syntax is different. I don't think that its much of a big deal to transition from AT&T syntax to PPC syntax. I know in the IA 32 systems, it runs in protected mode. But I am not sure about PPCs

Originally Posted by demosthenes2k8

I'm sorry, but you appear to have a need to overcomplicate everything. If there's really no need to write the code in assembly, it would probably be better to write it in C++, because the compiler can probably write better assembly than a human.

There is no need, but I have the mentality that I would learn so much more from it. I mean there is no NEED for me to even be on the team. You see where I am going with this?

[mikets]

Originally Posted by davidthefat

That is true, that was written for my computer, the thread started out as a general question and is becoming more specific. I know the PPC syntax is different. I don't think that its much of a big deal to transition from AT&T syntax to PPC syntax. I know in the IA 32 systems, it runs in protected mode. But I am not sure about PPCs

BTW, there is no AT&T syntax, you probably meant Intel syntax. Also. there is no IA32 system. There is IA64 but 32-bit system is called x86. IA64 is an entirely different 64-bit architecture from Intel. The curent 64-bit Intel processors x64 is different from IA64 (Itanium). All new Intel processors are now 64-bit processors but they are backward compatible with 32-bit (x86) systems.

[davidthefat]

Originally Posted by mikets

BTW, there is no AT&T syntax, you probably meant Intel syntax. Also. there is no IA32 system. There is IA64 but 32-bit system is called x86. IA64 is an entirely different 64-bit architecture from Intel. The curent 64-bit Intel processors x64 is different from IA64 (Itanium). All new Intel processors are now 64-bit processors but they are backward compatible with 32-bit (x86) systems.

According to Intel there is http://www.intel.com/products/processor/manuals/
And I read that Intanium was the one that was NOT compatible with x86, that is why Intel uses AMD's x86-64 architecture.

[Ether]

Originally Posted by demosthenes2k8

the compiler can probably write better assembly than a human.

Although I agree that it is seldom necessary (or desirable) to write assembly code, an experienced assembly programmer can in many cases implement optimizations that a compiler won't use. The downside is that the code can be a brittle maintenance nightmare.