Discussion
reading the amd64 architecture programmer's manual:
One of the more common types of strings used by applications are byte data-type strings known as ASCII strings, which can be used to represent character data.
i agree that a varint encoding like utf-8 sucks too, but come on
A data access is aligned if its address is a multiple of its operand size, in bytes.
i have never in my life read an explanation that explained this relationship or why it would matter to the processor
If you ever find out, please tell me, it sounds like it would be genuinely neat to know.
i now understand callee-saved! because when you're hand-coding assembly subroutines with PUSH/POP, you actually are using a got damn stack language. holy shit
so now i finally understand what the hell a frame pointer is and why it's optional
ok i was totally wrong because the frame pointer is used with ENTER to access parent stack frames by writing the frame pointers from N parent frames into the current stack frame (which is how you get & safety for reference arguments in rust, although i'm sure you could do this with the compiler alone)
The use of rSP or rBP as a base register in an address calculation implies the use of SS (stack segment) as the default segment. Using any other GPR as a base register without a segment-override prefix implies the use of the DS data segment as the default segment.
hmmmmmmmm ok so you can access a parent stack frame after ENTER by jumping from rBP to the desired stack depth (by incrementing 64 x number of frames to jump back), then dereferencing THAT address to get the parent stack frame locals start, then adding the desired offset into your language's per-stack locals, then dereferencing THAT address (without stack segment, just data segment)
....i think?
it almost seems easier to just use the compiler to remember the stack-relative offsets
i think the frame pointer is a separate kind of register area because otherwise i don't see how pop rBP for LEAVE could work
@hipsterelectron pop rBP
removes the current value of the base pointer, and restores the previous one (so, after the pop, it points back at the base of the instruction you're LEAVEing to), which it stored on the stack during 'ENTER'.
@miss_rodent oh holy shit i didn't realize push and pop could accept just any stack-relative address
@hipsterelectron I didn't think they can?
POP always removes the top, push pushes onto the top.
But when you are LEAVEing, you set the stack pointer = base pointer, then 'pop rBP' takes the top value of the stack (the previous routine's base pointer) and puts it into rBP (so it now points at the previous function's base)
fucking hilarious to see binary coded decimal instructions
yeah this document is completely fucking backwards from how i would write it. how on earth do you have "returning from procedures" semantics 20 pages after CALL and RET
it is kind of cool that the stack is actually a completely distinct data structure from the instruction pointer
3.7 Control Transfers
HELL YEAH MOTHERFUCKER LET'S GO
oh shit is code segment switching how shared libraries work
@hipsterelectron The answer to such questions is (nearly) always "no, but it sometimes was in the 1990s". The paged memory technique is more popular these days, as it makes it easy to implement memory protection too. (Manipulating this is what the mmap system call does.)
ring 0 example usage for "memory management, file allocation, interrupt handling" absoLUTELY not my sweetie!!! file allocation is ring 2 with the application-layer i/o runtime
so basically whenever they neg me about overhead but don't refer to something as explicitly deprecated i'm like hmmmm
3.7.7 System Calls
A disadvantage of far CALLs and far RETs is that they use segment-based protection and privilege-checking. This involves significant overhead associated with loading new segment selectors and their corresponding descriptors into the segment registers.
i hate it when my system calls use protection and privilege-checking
The overhead includes not only the time required to load the descriptors from memory
why would the descriptors not be in the cpu cache
but also the time required to perform the privilege, type, and limit checks.
don't tell me you made privilege checking slow
Privilege-changing CALLs to the operating system are slowed further by the control transfer through a gate descriptor.
completely unexplained. plus shadow stack sounds cool as shit
3.7.7.1 SYSCALL and SYSRET
SYSCALL and SYSRET are low-latency system-call and system-return control-transfer instructions.
latency latency latency. dogwhistle imho
They can be used in protected mode. These instructions eliminate segment-based privilege checking by using pre-determined target and return code segments and stack segments.
the call-gate descriptor sounds pretty predetermined
The operating system sets up and maintains the predetermined segments using special registers within the processor, so the segment descriptors do not need to be fetched from memory when the instructions are used.
so you're saying if i prefetch the segment descriptors before i CALL then i still win
The simplifications made to privilege checking allow SYSCALL and SYSRET to complete in far fewer processor clock cycles than CALL and RET.
how simple
SYSRET can only be used to return from CPL = 0 procedures
ok. so checking if CPL != 0 is faster than checking CPL_source < CPL_target
anyway it sounds cool. really i don't think numerically increasing rings are a correct model
you should be able to set up registers for SYSCALL and SYSRET for transfer between OS-defined privilege labels. 0 should be userspace. anything > 0 is a particular kind of communication boundary defined by the OS semantics, and not ordered. and registers for SYSCALL/SYSRET should specify a mask for input privilege labels and then a specific resulting privilege label
userspace exists because that's the C standard
as a pedant, this is my favorite control transfer:
3.7.10 Interrupts and Exceptions
Exceptions and software-initiated interrupts occur synchronously with respect to the processor clock.
every single fucking signal handler tutorial always mentions how they strike without warning. it's true--even the C standard says so--but like. lol. lmao
does the C standard require a clocked processor
Faults — A fault is a precise exception
ok, got it. a fault is precise
Generally,
sir
faults are caused by an undesirable error condition
like tennis. ok
although,
no. NO
some faults (such as page faults) are common and normal occurrences.
so i have an opinion about this
as someone who has constantly repeatedly restructured lazy computations (which end up pulling in tons and tons of i/o and computation, and effectively cannot be cached or prefetched) into clear data dependencies that can be scheduled, i think a page fault is in fact a failure of scheduling
@hipsterelectron Are there particular approaches for this? I've only got as far as observing that this restructuring is usually possible, often a good idea, and would be performed by a sufficiently-intelligent compiler / runtime, but I don't actually know how to do it.
first off, files are not pages. fuck off. you can map a shared memory region if you want shared memory
second, copy-on-write is a cheap hack for latency benchmarks and should never have been the default mechanism used for parallelism. it is an active abdication of scheduling the movement of memory across processes, because POSIX has absolutely no concept of any communication that's not instant!!!!! now!!!!!! everywhere!!!!!!!
@hipsterelectron The fork / exec, copy-on-write paradigm was designed for computers which only had one program loaded in memory at once, with the rest swapped to secondary storage. Fork creates a new process, but doesn't do much of anything else; and exec loads a new image over top of the current process.
On the systems it was originally designed for, spawning a new process always involved those two steps, and separating them gave you useful tools. Of course, this then became a standard API…
now, you won't hear me supporting microsoft's diatribe against fork(). not only EEE, but also a massive skill issue: https://www.microsoft.com/en-us/research/wp-content/uploads/2019/04/fork-hotos19.pdf
Moreover, a fundamental challenge with fork is that, since it conflates the process and the address space in which it runs,
ah. indeed. conflating a process. and an address space. the thing which is defined per-process
fork is hostile to user-mode implementation of OS functionality,
not mine!
breaking everything from buffered IO to kernel-bypass networking.
page faulting is breaking everything. i'm ruined. oh what a world what a world
Perhaps most problematically, fork doesn’t compose
it's actually quite a structured abstraction for multiprocessing. it's not perfect, but it's in the tool belt
every layer of a system from the kernel to the smallest user-mode library must support it.
again.........it's page faulting. cmon
Systems that support fork and exec efficiently are forced to duplicate per-process state lazily.
yes, that is how semantics for syscalls work. microsoft should try it
This encourages the centralisation of state, a major problem for systems not structured using monolithic kernels.
copy-on-write is very much not centralized. monolithic kernels actually have a much worse time doing this
On the other hand, research systems that avoid implementing fork are unable to run the enormous body of software that uses it.
ok. so you don't want to write a compatibility layer. but you feel entitled to the enormous body of software regardless
not even worth going past the first page. let's go back to what a fault is:
After the service routine completes, the machine state prior to the faulting instruction is restored, and the instruction is retried.
ah, so the machine state is completely unchanged after a page fault? because that sounds pretty compositional to me
ok, done with faults. next:
Traps — A trap is a precise exception
I'VE HEARD THIS ONE BEFORE
@hipsterelectron .... So fucking tempted to put "A precise exception" in my bio after reading this.
Software interrupts and certain breakpoint exceptions used in debugging are traps.
those are not the same thing, but that's fine
ah. now we learn:
Aborts — Aborts are imprecise exceptions.
"precision" has never, ever been defined before in this text. let's see if they're using higher-order logic:
The instruction causing the exception, and possibly an indeterminate additional number of instructions, complete execution before the service routine is invoked.
see i like this because it's async!!!! the processor should let me do some more async stuff!!!!
Because they are imprecise, aborts typically do not allow reliable program restart.
"imprecise" has NEVER been defined
