Continuing from previous post.

2020-02-06,07

It looks like I definitely need to add relative addressing mode. As I am reading K+R right now, I started wondering about how are "automatic" variables are created/implemented, and started searching info about it. This way I learned a lot about how stack operates, and about stack frames. This explanation is the best of all I've read.

It seems like having ability to push and pop one word at a time won't suffice for implementing proper function calls. (Well, there is still a way, but it is very awkward). So, I need to have the ability to access locations that are not only on the very top of stack, but a whole number of these locations (as many as needed for storing of all local variables and parameters for a given function. Having ability to access them by address which is known offset from known value (Stack Pointer or Frame Pointer) makes this much easier.
Thus it is now clear that addressing logic modification is needed, namely, adding an additional adder for calculating offset addresses. Now, as it became apparent that most of the circuitry will be muxes anyway, another adder now seems to be relatively small addition.
Given that there will be adder in addressing circuitry, then it seems logical to implement different additional addressing modes (various indexed ones). This of course would require yet another change to memory access decoding circuits.
These new modes should be mostly an addition to existing absolute addressing modes. One exception is that local (in-page) addressing will no longer be available -- this I already discarding with adding of byte addressing, as it adds much hassle for little gain.
Right now I could think of PC-relative and FP-relative (relative to Frame Pointer -- it is absent in simulation right now).
Also maybe GPR-relative mode also. The number of modes may be constrained by the number of available instruction bits.
Another implication of having an adder in addressing circuitry is that SP and PC are no longer need to be counters, but just a simple registers. On the other hand, after some thought, it looks like leaving these special registers the way they are now (counters which can auto-increment, and in case of SP, also auto-decrement) may serve a purpose - this way there is no need for dedicated hard-wired inputs of +2 and -2 for the address adder/subractor, so 2 inputs less to be multiplexed.
All of the above implies quite a bit of change have to be applied to the sumulation, as well as an assembler. As for the latter, I am already planning to rewrite it from scratch, in C rather than C++, in a way that will make it more plausible to write it in its own language eventually, i.e. make it native assemler, which will run on simulated (and hopefully physically built) computer, and produce code for that same computer. As of now it is of course a cross-assembler running on a PC.

On topic of building hardware -- I've built a board recently, which may become, at least temporarily, a part of this machine -- the 256bit PROM (16 x 16bit words), made of switch banks, N4148 diodes and a handful of logic ICs. I gather, at the building and debugging phase it will be handier than burning EEPROM for each change. As a preliminary testing result, it seems like it can handle accesses at 1MHz, though I don't think such performance will ever be needed for a 32-byte PROM.
This board is described in more detail in my other project.

--------------------------------

UPD 2022-11-07

Integer Calculator program

As of the start of the year 2020, I created assembly program for this version of ECM-16/ECM cpu, using the assembler I wrote earlier. This program is an integer calculator, i.e. it reads inputs as numbers and operators and returns the result.

For reading, it polls the Input register, and output is sent to segment digital display.

The calculator input and display are decimal integers.

After performing the operation, it halts, for the next operation reset is needed.

Here is screen capture showing how it works: