search

Colby-CPU-Sim / CPUSim

GNU General Public License v3.0
53 stars 19 forks source link

Replace "drag-and-drop" interface for Instruction spec with DSL #38

Open Nava2 opened 8 years ago

Nava2 commented 8 years ago

From an e-mail thread:

This leads into a new avenue of collaboration and design idea, I want to replace this interface: unnamed with a DSL that performs the same function, but in a more "programmatic" way. We believe this is beneficial because it keep students in a more familiar setting which is important for pedagogical reasons.

For example, instead of "drag and dropping" the instructions, it could be specified as below, while compiling to the microcodes specified for the processor.

mar.clear mar = ir[8:15] goto IO_IS_MAR if (mar == IO)

mdr = main[*mar] buf1 = mdr A[ir[5:7]] = buf1 exit

IO_IS_MAR: buf1 = input() A[ir[5:7]] = buf1

​In addition, because of the way this is defined, the microcodes interfaces could be organized to keep it more "component"-oriented. For example, instead of having "TransferRtoR" as a category, it'd be "Register IR" which new types could be added like "Transfer" or "Dereference" which then lets the syntax be used in the instruction specification.

This is all very "design"-heavy and unimplemented. But to do the DSL parsing, it's quite straight forward with projects like Xtext. The logic of discerning what is a valid "microcode" creates some interesting challenges, though.

We believe this is a good avenue of research from the pedagogical side and were going to do it via our original simulator, but I believe that's a waste of effort (a lot of reinventing the wheel for the core components). I've yet to talk to my two supervisors about coming back to this collaboration because I wanted to touch base with you if the idea makes sense within your visions.

This would also allow for specs such as #32.

Nava2 commented 7 years ago

I actually don't think this is a proper avenue of changes anymore. This space is such an internal fight for me: I like high-level constructs, but we are trying to teach low-level constructs. Thus, I think the original design is a better fit than my suggested path. My supervisor and I talked and he agreed, it would make things too high-level, detracting from the "intentional" (read: unfortunate 😄) difficulty that is hardware design.

@djskrien thoughts?

djskrien commented 7 years ago

I am happy to stick with the original design rather than use your DSL.