Potential Future Version Change Ideas

[Christopher Mar]

Dr. Sohoni asked me to post this list of ideas for things that can be worked for a future version of PLPTool and the PLP architecture.  We are hoping for feedback and ideas from anyone in this Google Group.

PLPTool Changes:

1. Change addresses to use 32-bit variables (could potentially reduce memory usage and resolve sign extension bugs)
2. CPU view disassembly instruction field breakdown (show opcode, registers and offset separately)
3. View PLP datapath during simulation (show control signals and bus values)
4. Make adding registers and memory addresses to the watcher window easier (include prefixes like ‘$' and ‘0x’)
5. Allow memory visualizer offset to be in words rather bytes

PLP Architecture Changes:

1. Add status register for arithmetic operation flags such as overflow, carry, negative, etc.
2. Add arithmetic shift instruction (sign extension shifting)

Thanks,

Chris

[fritz]

I can only speak to the hardware changes:

1. Why a status register? MIPS proper doesn't have a status register, but instead eventually got a coprocessor that had a status register (accessed with some special instructions). The MIPS pipeline is particularly simple because of the simple register file concept. Adding special registers and instructions to go with them can do some awkward things to the machine. That's not to say we don't need /something/, and maybe a status register is the right thing. I would just caution keeping in mind what is best for use in the classroom and implementation/modification by students. 

2. Seems simple enough to add arithmetic shift, as well as to finish the complement of arithmetic instructions. Having a full exception unit / status register / whatever you end up with will be needed here.

[Christopher Mar]

Both of the potential hardware I mention come from my undergraduate experience with Motorola 68000 processors.  Admittedly the 68k is a CISC and that's probably not a direction we want to take PLP.  I only brought up those two features because I found them particularly helpful during my experiences with the 68k and they would be very relevant to a calculator project the students currently do.

[Wira Mulia]

1. I think this would be too much work for a marginal gain. Unless we start simulating systems with gigabytes of memory, I don't think this will be a problem. We're currently only simulating 16MB of RAM (which means 32MB of storage for the values, the simulated memory is stored as an array). If we do simulate big systems, I'm sure we'll have to look at 64-bit also.

2. The disassembly view can be improved in a lot of ways :) That whole thing was a weekend project, ha. One thing that would be cool also in that CPU view is to have the register fields highlighted if it was modified in the last cycle.

3. Yep. I think this has been a goal for a while.

4. Shouldn't be too bad, I already handle some different representations, may just have to add few case statements depending on the prefix.

5. I'm okay with this.

arch:

1. Depending on how much do we want to diverge from MIPS, doing an architectural change like this would be huge in the long run. I agree with Fritz, caution is warranted.

--
You received this message because you are subscribed to the Google Groups "progressive-learning-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to progressive-learning...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.