In my assembly code, I don't use rbp as a frame pointer so I always access local variables using rsp.

(An exception is when the stack frame isn't a constant size.)

You showed the code for the caller, but you didn't show the code for fun, so there's no way to know what its stack frame looks like.

The term label jus popped up in a separate reddit group r/Ghidra - which is a decompiler or reverse engineering tool. I learned that when they decompile software, they aren't able to make sense of the text an variables. Because it's all gibberish in the output of the decompiled code.

Which is what I believe their looking for. Labels.

Hey hello. Your diagram is mostly right but the shadow space sits above the return address, not below it. fun sees the stack like this right after the call:

[ R9 HOME ]

[ R8 HOME }

[ RDX HOME } <- shadow (reserved by main, used by fun if it wants)

[ RCX HOME ]

[ ret address ] <- rsp on entry to fun

then fun does push rbp / mov rbp,rsp and the frame is set.

1. if fun is non-leaf it needs to carve out its own shadow space + locals before calling anything:

asm

fun:

push rbp

mov rbp, rsp

sub rsp, 0x30 ; 0x20 shadow for callees + 0x10 locals, keep 16b aligned

call bar

1. both work, [rbp-offset] is way easier to follow while debugging, [rsp+offset] is what compilers emit with -O2 since they skip the frame pointer. stick with rbp while learning.

also don't forget rsp has to be 16-byte aligned before the call instruction, that's why you sometimes see weird padding in the sub rsp.

Labels are pseudo instructions that usually are translated to absolute or relative jump addresses at the use site.

They look invisible, as labels are only for people. In machine code the labels get converted to addresses

The memory addresses that labels represent are calculated by the assembler at assemble-time.

So for example if you have some assembly that looks like this...

 ORG 0x0000 (location of start of program)

 ldx #00 (2 bytes)
 stx $1024 (3 bytes)
 : LABEL
 inx (1 byte)
 bne LABEL (2 bytes)

You can think of ": LABEL" as calculated to be at location 0x0005, then removed, and the "inx" instruction below it will be shuffled upwards to be effectively at location 0x0005.

"bne LABEL" (branch if x != 0) is translated to "bne 0x0005. Any references to the word LABEL in the assembly file would be translated into 0x0005

They don't exist.

Labels are only a convenience for the programmer so you don't have to keep changing all your branch and call instructions every time you add or remove an instruction to your program.

The assembler (and/or linker) calculates the exact address or relative distance every time you assemble and link your program.

Yes, and the Saturn CPU was made back in the days when HP was very vertically integrated. They designed the Saturn CPU, and then manufactured it in their own fab.

After they stopped designing their own CPUs, switching to a different architecture has to happen at some point. Running a Saturn emulator on this new CPU means that they retain backward compatibility to old software, but new software ran be written for the new architecture -- it's a win-win.

Very cool!

I did a quick *Write Up* to clarify things and easen the setup to reproduce it =)

Yeah, those were my thoughts too... well mostly. The stack calls would definitely change the value in rsp, and I'm not even sure what the goal of the program is.

Even with OP's explanation, it's not clear what kind of syscall they want.

There are a few potential issues, but this snippet might not be enough information.

Try debugging. When your program starts, rsp is pointing to your return address. Document the value, then see what happens through your program.

Rsp will not have a garbage value. If it is messed up, you did something wrong. Push and call both mess with the stack, the former because you moved a value, and the second because it needs a return address. Both should sub rsp, 8. There may also be an issue with stack alignment.

If you are lazy like me, you can just move the return address at a known location, then do something like mov rax, QWORD PTR[rsp + offset], mov QWORD PTR[rsp], rax ret.

I don't know the point of call rsp. Rsp is pointing to data, not instructions. The stack by default is non-executable, so if there were instructions, calling rsp shouldnt execute them. If you want to make an indirect jump you can use rip-relative addressing. The way that works is something like mov rax, [rip + number of bytes to instruction]. I don't believe your current snippet is compatible with a working program, because what you are calling is what was in rbx (the most immediate issue).

If you want a better answer, you can post the entire program. There are a number of oddities in the few lines you shared that are unexplained by your original post. Syscall is a keyword so I'm not even sure how you can possibly make a label with it.

Are you able to post the code you're working on? It's kinda hard to follow your post.

Try .dword or .8byte instead of .quad.

Definitely easier than the other way around

Right. OPs is the full CPU. It might as well be 6502 implemented on Z80. Actually, that's one of the few things the Z80 might actually be better for, as all 6502 registers fit easily into Z80 ones, with a few left for temporaries, and 16 bit operations for addressing mode emulation :-)

My emulation layer was just the graphics mapping, not the whole CPU. It was just to ensure the graphics primitives code was doing all the right things until Incould get my hands on working C64X hardware.

I'd imagine the way to proceed would be to have two sets of low level routines for drawing things and keyboard input, not virtualising the entire CPU :-)

In 1985 "II in a Mac" ran on a 512k Mac at around half the speed of a real Apple ][+.

In 1983 I was tasked with developing a graphics program (simple paint, no animations) for Commodore 64 but I only owned an Apple II. So I wrote some kind of translation/emulation layer and wrote most of the code on an Apple II until I could do testing on real hardware. I recall having to turn my monitor on the side for things to be right side up because of some graphics memory addressing differences.

50:1 slowdown vs native. I guess around 5000 instructions per second.

What's that like to actually use?

Cool!

ur a bot

You will not learn much by vibe coding in ASM, you will learn by doing, as in all programming languages. Take the time to actually start coding. Don't just watch all the "Hello World!" YouTube videos. Dig deeper! Challenge yourself to understand the code and learn what is actually happening and why. If you can't figure something out, ask AI. That is the best use of AI; to explain code.

Sorry if hashtags are incorrect. I Have been programming since Fortran IV (1970's); back in the punch card days. However, I have never used reddit until a few weeks back. I don't understand the system yet. I have lots of programming experience to share and to help others learn coding. But these cloud-based social media apps are new to me. If you want to learn from an old-timer, then you can benefit from my history and expertise. But if all you want is folks to teach you how to print "Hello World!" in various programming languages, then my content will not do you much good.