Table of Content  Branch Up  

Back to work

9/24/2010

I've taken this project back after a long pause and I've started by reviewing all of the "facts" most of them settled since many months ago. The architectural features are --I can see-- very mature at this point. Heritage/1 can definitely be described as a strict 16-bits "traditional" minicomputer based on single accumulator, single ALU, offering a --I would call it-- rich instructions set designed to execute simply and fast.

Features I really enjoy are the following:

- Instructions decoded by hardwired logic.
- Double-buffered registers.
- Not use of ROM

There are some features, however, that don't get to fit into the whole picture as for example the ability to disable the Timer by software (instruction DT: Disable Timer).

The idea behind the Timer was always the same it is still today: to assists a multiprogramming operating system in switching between processes. I've been always thought of the Timer as sort of "watch dog" sat there to make nearly impossible for a crashing process to hang the entire system... well, to try at least. So allowing routines to disable the Timer defeats its very purpose.

Today I decided to resolve the matter by getting back to the original idea that I've violated three month ago against my own sense of consistency. So, yes, I'm definitely removing instructions ET, DT from the Instructions Set as well as the TE flag (Timer Enabled) from the Flag's Register. Any solution for preventing critical-region code from being interrupted by the Timer's tic must be found within the OS design, not the CPU hardware.

It occurs to me, for example, that all system calls (issued asynchronically by processes) could wait in a "pending service queue" to be serviced later at "tic-time". Anyways, I'm not designing an Operating System yet so those issues will get actually solved in the future. For now I'm focusing in hardware design and I want it to be a clean one.