0

I'm trying to set the 0th element of an unsigned char array to the address of the nth element of a separate unsigned int array. I'm not sure if my syntax match ups with the addresses and pointers. (This is my main concern, in addition to any potential type conflicts.) I'm using chars because my assignment requests me to keep the data in an element to under 8 bits. This is a snippet of my implementation:

unsigned int memory_size = 100; // size of array 1
unsigned int other_memory_size = 100; // size of array 2

unsigned char *memory = NULL; // array 1
unsigned int *other_memory; // array 2

memory = new unsigned char (memory_size); // declare size
other_memory = new unsigned int (other_memory_size); // declare size

Finally, I want the first element in memory to be the address of an element in the other_array.

memory[0] = &other_memory[0];

Eclipse returns this error:

invalid conversion from 'unsigned int*' to 'unsigned char'

To resolve this, I changed all char declarations above to int declarations. The new error is:

invalid conversion from 'unsigned int*' to 'unsigned int'

Leading me to believe the types aren't the main issue here. Am I declaring points incorrectly, referencing addresses inappropriately? Please advise.

Christophe Brown
  • 77
  • 4
  • 12
  • 1
    C++ will not allow you to assign un-like types that have no conversion mechanism. You cannot assign a pointer to a non-pointer without brute force with shady casting tricks. You don't want to do shady casting tricks with pointers because they almost always blow up in your face. Please expand on your ultimate goal because right now it seems [you are fighting with the XY Problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem) and suggesting solutions to your asked question will get you no closer to completing the assignment. – user4581301 Feb 15 '18 at 00:49
  • I'm creating an Unpipelined MIPS Datapath in c++. My program reads in assembly instructions from a .asm file, storing components of each instruction into an array, in this case other_memory. For example, I have insturuction XOR R0 R0 R0. other_memory[0] holds a 6 (which corresponds to XOR for my program), [1] hold a 0, [2] holds a 0, and [3] holds a 0. My program counter (PC) is the first element in memory[]. That stores the address of the instruction components. The PC is supposed to hold the location of the beginning of an instruction, which is the element for the XORs, LDRs, ADDs, so on. – Christophe Brown Feb 15 '18 at 00:56
  • 1
    I think you can simplify what you're trying to do quite a bit. It sounds to me like all you need is a single array (prefer a `vector` if you don't know the size ahead of time) of bytes and the index into the array/`vector` as the PC. I see no need for `other_memory`. You might want to draw yourself a few pictures of how you think this should lay out in memory. – user4581301 Feb 15 '18 at 01:09
  • The reason I use two arrays is because one acts as host for the instructions, the other consists of special purpose registers, including the Program Counter, Next Program Counter, ALU Output, Immediate, etc. (I don't know if you have a background in computer architecture, but this is what I know as I'm taking a course in that subject now.) – Christophe Brown Feb 15 '18 at 01:21
  • Minimal background in MIPS. took a course on it somewhere around 20 years ago. Most of my assembly work was done on Motorola chips. Are all of the special purpose registers the same? If not, you can't pack them all onto one array without mucking about with `union`s and `variant`s. For example ALU Output is most likely not a pointer, so it can't coexist with PC as a pointer But if PC is just an index into your instruction cache array... now you're talking. – user4581301 Feb 15 '18 at 01:34

2 Answers2

0

You have to specify that your memory array is made up of unsigned int*, and not unsigned int. This is because in this case C++ is statically typed, which means that it will enforce rules about what types can be assigned to variables based on their types.

9y7h0n
  • 326
  • 1
  • 8
0

First of all, your new syntax is wrong; array dimensions go in [], not ().

Now. Two compiler errors about mismatched types and this brought you to the conclusion that "types aren't the main issue here"? Types certainly are the main issue here: you are trying to store an unsigned char* as an unsigned int. Don't be misled by the fact that we sometimes represent pointer values in numerical form: those are two different things and, though C++ does provide some utilities to convert between the two (kind of), it knows that this is usually the wrong thing to do, so doesn't allow it as an implicit conversion.

So, you can't just randomly throw different types at the problem and get it done; if you want to store pointers, store pointers. If you have a real need to store a pointer as an integer, you could consider uintptr_t, but I'm betting you don't.

Thus, perhaps:

unsigned char** other_memory = new unsigned char*[other_memory_size]();

Or, better yet:

std::vector<unsigned char*> other_memory;

These containers will accept pointers.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
  • I should have been more specific, in that my major issue was with matching up pointers versus the more obvious conflict between int and char. Your first proposed revision resolved the point mismatches. I've also converted everything to type int for now to continue development. – Christophe Brown Feb 15 '18 at 01:33
  • If your intent is still to "store pointers", then "converting everything to type int" is not a forwards step. – Lightness Races in Orbit Feb 15 '18 at 01:35