MIPS, DOS

[ybakos]

This message is intended for the authors, or anyone who has spent significant time with the tools' source code.

I'm wondering how feasible it might be to create an 'advanced' CPU project based on the MIPS architecture. Perhaps there would be little value there, since the principles of CPUs are, in my opinion, well defined by the book/project work. But it would expose the students to a more 'real world' architecture that's a little more complex than the Hack CPU.

Second, I'm wondering how feasible it might be to extend the existing codebase to accommodate the development of a BIOS, hard disk interface, and a disk-based operating system. In my mind, this would be a great "chapter 13/14" in which students implement the ROM/BIOS, bootstrap loader, DOS, command interpreter, and even a basic shell.

I have a graduate student who may be able to devote time to such a project, assuming the existing material can be extended in such a fashion. (I apologize for not doing my due diligence w/ the source code yet.)

Noam & Shimon, did you guys spend any time thinking about this when designing Hack?

[Warren Toomey]

I was thinking along similar lines, for example to have "breakout" chapters where the original design could be extended. One idea was to have a second ROM32K which would be used as a microcode lookup table, so that the instruction set can be "programmed".

I think a MIPS-style CPU would be hard to build from scratch, but adding some extra general purpose registers and changing the assembly-language syntax to a more customary one is possible, see my ideas here.

[Brian Makin]

Implementing mips would be fairly hard... but building more/advanced features into what we have would work

[ybakos]

Yes, the MIPS thing is certainly a super-challenge. Just wondering about what the implications would be from the perspective of the tools.

[Noam]

The hardware simulator is completely general (except for not allowing un-clocked loops -- which you would not need for anything), so it should be possible to either have hardware additions or even go all the way to MIPS. Due to the scale of something like MIPS, though, you would want to program new built-in versions for intermediate chips in the design, otherwise the simulation will just be too slow (or even run out of memory).  This should not be too difficult -- the "builtin chip" interface in the code is general, and I believe pretty easy to use.

Now, in terms of software anything can be done of course, but any change to any of the languages will require writing a new simulator or translator (or at least modifying the current ones), if you want to have this intermediate layer of supports for the students.  The CPU and VM emulators that we provide are quite specific and not designed for general extensions.

[Noam]

Another point: the direction of adding a "disk" and then providing everything up to a "shell" that allows running programs is indeed quite attempting.  In the hardware level this mostly requires: (1) designing a builtin "disk"-like chip and interface (2) moving to a single address space that holds both program and data (3) you would probably need to increase the address space to hold larger programs (4) decide whether you want to bypass using "hardware interrupts" or add them.   However, I think that at the various levels of the software hierarchy, a significant amount of new stuff is needed for even the simplest shell.  All in all, my impression is that this would more than double the amount of effort involved.

[BrettNewman]

Just wondering about what the implications would be from the perspective of the tools.

[Advertising deleted by admin.]