Load and Store Word Sign Extension Bug

[Christopher Mar]

I am a TA for Dr. Sohoni in CST 250 at ASU.  I have been working with Damon Cost on making PLPTool more accessible for a blind student in our class.  Today a student found a issue where using a negative offset in a load word instruction caused an error stating that the address not in any module's address space.  

I was able to duplicate the error on my own computer and after doing the address offset sign extension and addition I noticed that the address PLPTool was attempting to access had 9 hex digits meaning the address was greater than 32 bits.  If the number had been truncated to 32 bits the address would be correct, but the resulting address appeared to be stored in a 64 bit variable so the sign extension did not match the size of the variable.

I found the where the memory address was being calculated in SimCore.java (around line 606) and masked the resulting address with 0xFFFFFFFFL. I copied and commented out the original lines as follows:

Load Word Changes:

//Long data = (Long) bus.read(s + s_imm);

Long data = (Long) bus.read((s + s_imm) & 0xFFFFFFFFL);

Store Word Changes:

//ret = bus.write(s + s_imm, regfile.read(rt), false);

ret = bus.write((s + s_imm) & 0xFFFFFFFFL, regfile.read(rt), false);

After building PLPTool with these changes, negative offsets work as expected.  For anyone who has in-depth knowledge of the simulator implementation, is there any reason why addresses are longs (64 bits in Java) rather than ints (32 bits in Java) since PLP is a 32 bit architecture?

Thanks,

Chris 

[fritz]

Wira should have responded to this by now - in short it's a limitation of the Java language spec. There may still be a bug here though.

[Wira Mulia]

That is a bug in the functional simulator. Apparently nobody has tried to do negative offset with lw/sw with the functional simulation mode (the stack push/pop pseudo-ops are broken too). I fixed this on 5.1 on my website. I can't push to the PLP github for some reason. The provided fix in the post should be fine also (the cycle-accurate step method has this mask already).

The reason for using long (and Long) is because there is no unsigned primitive type in Java. It's just nice to be able to have the whole 32-bit range as unsigned in the language. I think using int everywhere internally is not a big problem, just have to be careful when displaying a representation of the value to the user. We used long instead so we can treat everything as unsigned and mask off as required. Some parts of PLPTool also treat negative values as error codes (e.g. the label address lookup method from the toolbox returns -1 if it can't find the label in the symbol table).

If we are going to support 64-bit architectures, we may have to use our own class instead of primitives to pass around addresses and values. This will render many parts of the core framework in PLPTool pretty much obsolete as everything expects a Long or long, but it's not that tall of a task to do.

[Christopher Mar]

Thanks for the reply.  The design choice to use longs makes sense now.  I am much more comfortable with C/C++ where there are unsigned primitives and I haven't had a reason to use them in Java before.

In what way are the stack push/pop pseudo-ops broken?  I haven't experienced any problems with them in PLPTool 4.1 or 5.0.

The ownership of the GitHub repository was recently changed and it appears you weren't added back.  I am one of the owners along with Dr. Sohoni and Fritz.  If you reply privately with your GitHub username I will add you as an owner.

- Chris