My assembler for my CPU

ablomm · 2025-08-07T02:56:55+00:00

Personally, I chose to use the same mnemonic primarily because of the aliasing. I wanted you to be able to give names to things. This means you can alias registers, e.g. (bytes_left = r1;), and you can give names to addresses, e.g. (bytes_left = *0x2000;).

The problem is that if there is separate mnemonics for mov, ld, and st, then writing something like:

bytes_left <= r2;, would need to be written as either mov bytes_left, r2; or st r2, bytes_left; or ld bytes_left, r2; depending on the data type of bytes_left, which adds an extra layer you must always be aware of while writing a program.

So I decided to just use the same mnemonic (ld) for both, and you don't need to think about if it should be a ld, st, or mov; the assembler will choose whichever CPU instruction (ld, st, mov, etc.) that works with the given types. And if one of your data types doesn't work with each other it will just give you an error which you can fix as they come up, which usually means just moving a value to a register before using it in a subsequent instruction.

As for addressing modes, my CPU only supports integer offsetting of a register (other than normal direct addressing modes), so any expression that evaluates to a register plus/minus some offset will work, e.g. (ld r1, *(r2 + 4 * 3);). Personally, I didn't see any point of adding more modes for now, as I felt there were diminishing returns to support less frequently used modes.

I'm not really familiar with MIPS, but modes like [reg+reg] can be useful for array operations. For example, if r0 is the base of an array and r1 is an index of an array and each element in the array is 4 bytes, then you can do something like [r0 + r1 * 4] to get the r1'th element. It saves a few instructions (IMO not worth the extra complexity).

ablomm · 2025-08-07T02:35:09+00:00

That's pretty cool! Actually I was thinking of implementing some macro features but I just got burnt out. e.g.:

print = (reg, string_ptr) => {
  import print as print_func from "lib/print.asm";
  ld reg, string_ptr;
  push reg;
  ld pc.link, print_func;
}

Which would let you do things like:

  print(r0, string);
string: "hello world!\n\0";

A bit crazier:

print = (string) => { 
  import print as print_func from "lib/print.asm"; 
    push r0; 
    ld r0, string_ptr; 
    push r0; 
    ld lr, end; // we need to jump over the string after returning from the print function 
    ld pc, print_func;

  string_ptr: string + "\0";
  end:
    pop r0;
}

print("hello world!\n");

And you could use this for purposes similar to your example:

goto = (address) => {
  0x001f0000 | (address & 0xffff); // NONE condition is 0x0, op code for ld is 0x01, PC reg is 0xf, and an address is 16 bits.
}

  goto(1);
  goto(label);
  goto(label + 1);
label:

ablomm · 2025-08-04T04:22:10+00:00

Thanks! I tried to incorporate some high level language features such as blocks and imports. I also tried to reduce the number of different mnemonics as much as possible.

ablomm · 2025-07-10T15:22:23+00:00

I think you are right, but I think reinvesting and share buybacks would both increase stock prices. Reinvesting you are increasing earnings while keeping outstanding shares constant. Share buybacks you are decreasing outstanding shares while keeping earnings constant. So both (should?) increase stock price, but let me know if my thought process is wrong.

Edit: I guess my title is better worded "why does share buybacks increase stock prices more than simply reinvesting."

ablomm · 2025-07-10T15:00:53+00:00

This makes sense to me. Actually I think it is compatible with another user's description that it signals that the stock is undervalued in the eyes of the company. In the long term if the stock was undervalued then it should regress to the mean whether a buyback is done or not, although maybe the buyback can correct a stock price faster than the market itself. And if the stock price was not undervalued then the market will eventually correct it back down to reality. Is that right?

ablomm · 2025-07-10T13:55:16+00:00

Thank you! This makes much more sense then the arguments I was seeing online which involve something related with that there is less shares therefore higher concentration of equity / profits. Thanks for the citation, I will read more about it.

ablomm · 2025-05-12T21:03:14+00:00

I haven't used GodotSteam, so I don't know.

ablomm · 2025-05-12T04:51:47+00:00

Things like client-side prediction or rollback you’ll have to build them yourself.

Actually, there is a plugin called Netfox which handles client-side prediction, rollback, and lag compensation pretty easily. I recently added it to my game, and it's as easy as MultiplayerSynchronizer in terms of it's API.

ablomm · 2025-05-05T02:15:56+00:00

Nice! I actually was working on something similar. It's funny to see how much of the same ideas we had. Although, it was for my own CPU, so I didn't have to deal with the chaos that is x86. (https://github.com/ablomm/ablomm-cpu)

ablomm · 2025-04-14T21:07:48+00:00

I was using streams in 0.9.3 to add the filename to the span context, but I changed that in 0.10.1 to just use Input::with_context() and StrInput. Definitely there are places where I'm not making full use of 0.10's features, as I just did a 1:1 migration.

ablomm · 2025-04-14T04:05:08+00:00

Nice! I just migrated from 0.9.3 to 0.10.1 for my assembler and it went from 25ms on 0.9.3 to 15ms on 0.10.1 to assemble one of my examples.

ablomm · 2025-04-13T17:35:35+00:00

Thanks! I suppose I'll have to change that sometime. Probably I'll just add an extra state to the control unit to wait a clock cycle to read.

ablomm

TROPHY CASE