Sometimes I really miss programming in asm, but it can be difficult to do on x86 systems. So basically my problem is that I have an array of chars, but I need to read and write multiple types from it. Ranging from 32 bit longs, 16 bit words, and 8 bit bytes. Now the solution would be easy in asm, but this is C++ here which thinks that restricting a programmer from low-level access is a good thing.
char * memory = new char[0xFFFF];


int readmemory_long(int pointer)
{
unsigned int r_pointer = pointer - 0xA4000000;            //converts given pointer to the array address
if (r_pointer > 0x1FFFFF) return 0;
return ntohl(memory[r_pointer]);                    //ntohl(), converts data to little endian (I hope :P) issue here
                                                               // I want to get the 32 bit value at this address
}
void writememory_long(int pointer, int data)
{
unsigned int r_pointer = pointer - 0xA4000000;
if (r_pointer > 0x1FFFFF) return;
memory[r_pointer] = htonl(data);                //converts data to big endian: same issue
}I was considering using for loops, but that could be kinda tricky. Any ideas/examples would be smiled upon 

First of all, this kind of code effectively byte-swaps the integer twice:

   int temp = int(memory[r_pointer]) * 0x1000000;
   temp |= int(memory[r_pointer + 1]) * 0x10000;
   temp |= int(memory[r_pointer + 2]) * 0x100;
   temp |= int(memory[r_pointer + 3]);
   return ntohl(temp);

If you read the integer byte-by-byte, with the multipliers being for big-endian, then it's already correct and you don't need to use ntohl.

If you want to read the integer all at once, use a pointer cast: *(int *)&memory[r_pointer]. If you do this, then the integer will have its bytes in the wrong order (because x86 is little-endian), and then you would need something like ntohl to fix it: ntohl(*(int *)&memory[r_pointer]).

As for your input loop: There are a couple of problems. First, prog_index needs to be initialized to some value (I assume you intended 0) - otherwise, you could be writing anywhere. Second, if the input file is in hex, then you need to parse the hex numbers. istream.read() just reads raw bytes, so if the file contains 70 01... then buffer will take on values of 0x37, 0x30, 0x20, 0x30, 0x31... In C++, you can instead use the >> operator. You'll have to set the stream to hex mode first though. You will also have to change buffer to be an int, not a char, because >> determines what to do based on the type of the variable on the right: if the variable is a char, >> just reads a character; if the variable is an int, >> reads a space-delimited number.

Corrected input loop:

   program >> hex;
   int buffer;
   program >> buffer;
   int prog_index = 0;
   while(program.good())
   {
      writememory_byte(prog_index + 0xA4000000, buffer);
      prog_index++;
      program >> buffer;
   }

Goplat, if it's parsing "70" to the ASCII codes 0x37 and 0x30, then "01" would read 0x3031, not 0x3001. 0x01 is a non-printable ASCII control character.

Well another error, but I bet it is the last difficult to fix one because everything else is easy to trace or has already been solved. I have one function in my program that takes the current instruction (type short) then runs through an else if block to find the corresponding instruction type. Because each instruction has several variations of its own type I preform an & to remove the dynamic bits of that instruction to leave only the static ones.
if (ADD_v == instruction & ADD_v) 
ADD();

else if (MOVi_v == instruction & MOVi_v)
MOVi();

else if (ADDi_v == instruction & ADDi_v)
ADDi();

else if (MOVLi_v == instruction & MOVLi_v) 
MOVLi();You might recognize these as SH3 opcodes.(don't worry there are many more in my code) The first instruction in memory is $7001 aka ADD $01,R0. Now I have a debug statement right after data is loaded into instruction and that reads $7001 as expected. Now this instruction is represented by ADDi_v which is defined earlier as $7000. So if I do $7001 & $7000, I should get $7000 which would equal ADDi_v. But my program doesn't seem to respond to this for some reason.

Edit: changed MOVi_v to ADDi_v. Just a typo

Thanks Goplat. Almost everything is working now. With a few more edits, optimizations, removal of debugs, documentation, and a better sample program, Spectrum should be ready for release tomorrow.

Side Note:
My eyes lit up with happiness when I saw R0 increment on the register screen.   I became crestfallen when my branching statement epically failed.