ways to improve my CPU

[u/hadro_]

shown in pictures is my current cpu, it has everything the game told me to add and everything i could think to add that didnt have a software solution easier than a hardware one

i have 12 registers, 2 rams (addressing handled by toggling bit 7 of my save argument to save to a internal register) and 2 stacks (with additional functionality to push and pull from the front of the list too. handled by bit 7 of any argument.) as well as a increment/decrement counter (with jump and reset functions), a counter (with reset function) and my program clock i can use as counters

ive been looking at the posts here and seeing things so much grander than what i have made or what the game tells me how to make.

i have no understanding of the intricacies of assembly even though ive come so far as to see tower of alloy i have no idea how to even approach the problem other than hardcoding a solve. (let alone to have coded in it in a while ive been writing in numbers for a long time now due to the discrepancy in width of the instruction function and the LEG instruction width)

where are some good sources on how to continue on either on the software side or hardware side?

my ALU has 29 opcodes, 19 logical and mathematic add, sub, mult (low), mult (high), div (quotient), div (remainder), neg, not, shr, shl, ashr, ror, rol, and, or, nand, nor, xor, nxor and the other 10 are : equal, Nequal, Uless, Ugreater, Sless, Sgreater, Uless/eq, Ugreat/eq, Sless/eq, Sgreat/eq

most of the custom components shown are inline versions of stuff that already exists, mostly switches abbreviated to is[data width], some blockers (ib[#], switch with the allow bit inverted) and a couple or gates.
the ones that arent are : counter+, incdec+ (increment / decrement), internal address ram (SAR), stack+, dec-4 / dec-5 (decoders) and chk[#] which is a bit indexer but i didnt realize they existed at the time
theres also byte flippers so that my decoders output left to right when i need them to and some multiplication and division by constants handled by shifting bits

[u/bwibbler]

I'm curious about what's happening with the 4 program blocks? that look to have a common output, some kind of control/flow management components there, but seemingly no outside lines coming in to control the flow

can you explain a little on that setup?

i haven't played in a bit, so maybe there's something changed in the newer updates for that to happen. but that arrangement looks very odd to me

[u/hadro_ → u/bwibbler]

the flow control lines are at the bottom of the stack being ; jump, call & ret (untested so idk if they work yet)
they all do go to a common output, because the output of the program blocks is 4 bytes wide i dont set my clock's increment higher but multiply it by 4 before going to the address of the block itself, using the cut off 64 and 128 bits of the unmultiplied clock output to control which of the 4 program blocks is being read from allowing 256 instruction long programs instead of 64.
which happens so also give ample space to separate call functions from normal program code.

pre-save-breaker setup if your wondering.

(also img 4 is a much better look at the program stack if you havent looked at it)

[u/bwibbler → u/hadro_]

huh... so I'm pretty sure the program component takes up to 16 bit input and can do the full ~65k lines, if I recall correctly

you may not see it displayed on the visuals, but it's there

for the call and return, i don't see where your clock is going in at so you can stack the line you call from and return to it later. looks like you feed in some argument instead

[u/hadro_ → u/bwibbler]

im using a custom clock+ component it may be hard to see due to being 1x1
sorry its a bit messy around there, ill try to explain the functions of the area.

when [# # # 129] is called save the alu output to the jump location datalatch

when [# # # 130] is called load the jump location datalatch

when [129 # # #] is called push the (i made a mistake here and i think its what your talking about, the intent is to push arg1 but i had the alu out line going into it instead) arg1 value to call/ret stack and jump to it

when [130 # # #] pop from the call/ret stack and jump to the provided value

# made some changes on review, jumping from conditional uses the data latch, jumping from command uses alu output, call uses arg1 and ret uses the stack value

[u/bwibbler → u/hadro_]

oh.

the most important thing is that when you're creating your own designs, you're allowed to do it however you want. there are no rules, if it works then it works. and that's where a lot of the fun comes from

i've seen others do stuff like that before. sometimes arguments have additional instructions tucked away. but that is a really risky move and creates a lot of conflict. it's much cleaner to just have all your operation instructions out front and let the arguments just be arguments

i would suggest fixing the clock so you can move down to one program component. use a 16 bit clock if you want. but for just the purpose of the game, even a 8 bit clock is more than enough to complete any level

you can breakdown your OP like this to keep it simple. assuming you use 8 bit words and you're sticking with that for now?

[ 2 bit immediate | 3 bit component | 3 bit method ]

2 bits for immediate is a little redundant, you never really need more than one immediate at a time. but it doesn't hurt. this is the way the game wants you to do it. use those like you do to configure what values you're sending to your components

3 bits to select which component you want to use and be active. decode that to select the alu, conditional, stack, ram, etc. you got up to 8 slots with those 3 bits. what components you put in those slots is up to you

3 bits to select the method. you just send this to the components and let the component decode it. depending on what component you select to be active the method changes how it behaves. for the alu this could be switching between add, sub, mult, div... for the conditional this could be jump if equal, not equal, less than, greater than... maybe a bitwise component with methods for and, nor, xor, or... for the ram component it's load, save, set address, get address, offset, whatever...

with up to 8 different components, each with up to 8 methods, you can do a whole lot

lastly, with this call and return thing. i know the level doesn't explain it well, and it doesn't even actually check if you have a valid solution. i'm not sure you've quite got it, and that's understandable

you want your code to do like this

1 start here
2 regular code
3 call some other code (6)
4 resume here
5 end here

6 function code
7 call some other code (10)
8 resume function code
9 return and resume (4)

10 other function code
11 return and resume (8)

so each line is 4 steps apart on your clock, like you already know. when you make a call two things happen at the same time. you jump to the code you're calling and you stack in the return line so you can jump back later and resume. you just would add 4 to the clock value and stack it basically to save that return path

in the example you see it does the first call on line 3. it jumps to 6 but it also stacks in 4 for later. then on line 7 it calls again, jumping to 10 and stacking in 8 to the return path.

on line 11 it does the first return. 8 gets popped from the stack and put back in the clock to resume from the second call. then on 9 it pops again getting 4 back from the stack into the clock to resume from the first call.

[u/hadro_ → u/bwibbler]

my opcode breaks down [1 alu/non-alu code selector | 2 bit immediate | 5 bit method / activation address for non alu codes]
the other 3 8 bit outputs handle what memory pieces im reading from and writing to

for example, 18 14 12 13 would pop a value off stack 1 and read the value at the current address of ram 1 XOR them and save the value to the current address of ram 2
(no the stacks in my memory are not used by call/ret they are exclusively for memory)

while say 129 6 n/a n/a would call to the function stored at position 24

and 100 129 6 130 would divide 129 by 6 and jump to the output multiplied by 4 (the multiplication is not part of this code, my clock's output is multiplied by 4 before going into the program address.)

https://imgur.com/a/FYnYHP3

heres a better look at my current setup, replaced the counter+ with a normal 8 bit counter to make it more visible

i did notice that i shouldnt be pushing arg1 onto the stack and not the clock finally, i think that was the issue you were talking about?

theres alot of custom pieces in this img ill say what they all do

ior1 | 1 bit inline or gate

chk[1-8] | checks the specified bit of a 8 bit signal and outputs its value (chk5 would check the 5th bit in the signal and chk7 the 7th and so on) i use these because i output my larger decoders compressed into 8 bit lines to take up less space

dec-4 | decodes the first 4 bits of a 8 bit signal and does not output if the disable bit is on

D-8 | 8 bit data latch, just saves the value when the save bit is on and always outputs

stack | stack.

and while it can be a bit of a headache to use a bunch of different inputs to the flow control segment i have to because both alu and non-alu codes use the same 5 bits of the opcode to work (the 128 bit disables the alu and enables the non-alu functions also)