waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhh

it went perfectly fine. they said my id was enough, and made no other comment. i don't even know if they noticed it wasnt real id.

the xIBIS architecture (in progress) with decoders that have been shrunk by ~2x since the last post. the main decoder is the toothbrush-shaped thing, a bit above the "opcode" word. however, the ALU-specific decoder wasn't shrunk, and can't be, since it checks individual lines. that one can be seen to the southeast of the main decoder, and is attached to the same blue bus that the main decoder and the opcode input are attached to.

I have once again massively compressed my decoder. this is so fucking epic.

so you just go through the normal line?

here's a register thing i (semi-originally) made, to attract attention to it. the latch design is definitely not mine though. but i like my compact routing of the write-enable.

epic hair woah

does anyone have info on going through TSA without real id? i have to do it in 2 days. TSA officially recognizes this procedure and says so on their site. i've spoken to people who have done this after may this year, and got through. just wondering if there are tips on what to bring and what to say

it's register time

there is a major difference between the main ROM and the ALU ROM. the main ROM has both a decoder and an encoder smashed together. however, the ALU only has an encoder that checks for very particular instructions. and each instruction has specific flags that it activates. see the forking traces.

the main decoder is in the top left (the dense rectangle). the ALU is on the bottom. the ALU's dedicated ROM is the small, dense rectangle, in the middle of the screen, that looks like a mini ROM.

i realized that the ROM would grow rapidly as control lines and instructions were added, so i instead opted to have separate ROMs for domain-specific lines, like ALU logic. it resulted in massive EPS and space savings

it's pretty smart tbh. i strongly considered just doing the CU ROM with a single demuxer, with a single predicate per control line. but i realized that would probably just take up more space and honestly be WAY harder to do anyway.

the translated ROM, as defined in the csv file. thanks VCBTool for making it for me.

im not a mad woman anymore.. jk, but i dont write csv by hand most of the time (anymore). i just use the vscode extension. but i was close to just doing it by hand TBH. still, VCBTool saves me a lot of time here with making the ROM.

"completed" control unit ROM csv file

i will need SO MANY more lines than this. i anticipate writeback making me go to hell or something. but anyway. it's done for as much as i can conceive right now. i'm pretty drunk on prog though.

a csv editor open to mapping opcodes to control line values, for use in CPU control-unit ROM

time to control some control lines

i just 36RPM'd wife in her office chair for 21 revolutions

whoops my old code was terribly flawed because ret was looking at the A argument instead of the return address

binary with annotations of what lines of asm the correspond to

well im happy i discovered this

screenshot of an untested function that is fed 7 arguments, and attempts to return the value contained in argument 6 using pointer arithmetic relative to the base pointer. i have no inline arithmetic for the base pointer, so this is probably the simplest way for now. i wonder if i'm going insane or if this actually has to be done this way. it's hard for me to conceptualize the difference between constant/static and runtime when it comes to assembly, cause it's just so different from system-level languages. i sat there staring at the screen for many minutes before i realized i had to add the m[reg] capability for load. and i can't do arithmetic on that either since it's "runtime". it's hard to explain because i haven't wrapped my head around it.

im starting to wonder if im insane. i have the ret operation set the returning sp to the outer bp, so not popping is okay? i just don't have a way to do pointer arithmetic inline. it has to be done with so many instructions lol. in normal-people assembly i'm pretty sure it's like "mov [ebp-4], 3"

and of course, if you break calling convention, and pass 5 arguments to a function that takes 3, then you will be faced with the cpu trying to return to the address of the value of argument 4, and two extra words will be left on the stack as well after that. so don't do that.

and what ret will see is %111, because it will be popping the final word off the stack. that's why we push the return address first, since it will be accessed last. and that's why this weird macro is needed.

as we can see, the first push, at 0x0C, pushes the return address of %111, which points to the jump at 0x1C since we use 4-byte addressing. also, the arguments are pushed in reverse order, as 3, 2, 1. at 0x1C, we have the jump instruction, to go to %1010, which is 0x2C here. ret is at 0x40.

i've since made the calling convention macro pretty nice. it automatically reverses the argument order since they're popped LIFO

the calling convention in action. i will need to abstract it more later.

the macros i've written so far for making the calling convention work

i'm working on a calling convention. i think it's really cool that customasm lets me statically determine the return address (which MUST be pushed first) by checking the size of the instructions for pushing the arguments. the alternative would be using a dedicated register, which sucks.

i actually have no idea how ptr[] and mem[] is used in normal-people assembly. but i made the syntax more explicit to make it easier to learn and remember my own ISA as i look at it

I forgot to mention that the numbers in parenthesis are tick timings. It shows that my adder has a max delay of 18 ticks.

My ALU/adder thing as a svg graph using graphviz dot and VCBTool

Here's my adder as an SVG (left), and a whole CPU someone else made (right). I made the graph with graphviz and VCBTool. It's pretty cool.

and going by the highest entity density ive ever seen, someone's transistor-logic-level implementation of the 68k in VCB would actually have been able to fit in about 6-7% of the 2048^2 canvas. imagine a CPU with that same high entity density that fills the canvas... that's my real inspiration.

I DIDN'T MAKE THIS ONE! This is a medium-sized CPU I found on the VCB Discord.

also (I DIDN'T MAKE THIS ONE) i just wanted to share how satisfying this other cpu someone else made is shaped. it's an inspiration. though its entity density is actually fairly low somehow, even though it looks so compact.

i'm struggling with endianness in customasm. i want things like amount_of_pee to be most-significant-byte aligned, or to be able to easily reverse the amount_of_cum string or something. i don't really know. curious if anyone has solution

the weird red square next to the variable defs is just silly vscode extension stuff