Man how do you even connect to a db with assembly code? Are there assembly libraries?
In theory I understand it but the monumental amount of effort it would take to write such “simple” things would take so much time
In theory I understand it but the monumental amount of effort it would take to write such “simple” things would take so much time
If it’s just a bunch of calling C code then I have to ask which part of this is actually assembly
The C# code you write (and majority of the your code's dependencies) are JIT compiled to native machine code (or more recently there are AOT compilation options).
A basic implementation of that is totally possible in assembly with no calls to c libraries. Would even be a great project for people to learn some systems programming. Keep in mind, all of these protocols (except maybe web sockets) were designed when programming in assembler was common. There's probably some HTTP implementation in the wild doing the same thing.
That said there's a lot of reasons you probably don't want to do that, HTTP can be subtle and you probably don't want to be doing raw clone3 calls to spawn threads, if you want to be doing thread or process per connection in the first place.
You can certainly write your own TCP/IP stack with raw sockets and directly interface with the NIC, if you like. But at that point you're both reinventing the wheel and bypassing the entirety of the OS, you might as well just write a forum exokernel.
Most developers don't consider utilizing a library in another language as "cheating". Popular and core Rust, D, C++, Python, nodeJS, etc libraries do this all the time.
When you program in assembly you're basically just doing the job of the compiler, and can call all the same library functions C code can. You just have to follow the calling conventions of the architecture. It's cumbersome and tedious, but nowhere near impossible.
x64 made calling functions more annoying by using registers then spilling over into the stack after exhausting those. x32 was more pleasant by far, since it only used the stack. x64's convention produces faster code though, by keeping stuff in registers.
Maybe I misunderstand you, but this is completely dependent on compiler, operating system etc, there are multiple calling conventions for x86-32, eg. cdecl, fastcall ...
> Argument words are pushed onto the stack in reverse order (that is, the
> rightmost argument in C call syntax has the highest address), preserving the
> stack’s word alignment. All incoming arguments appear on the stack, resid-
> ing in the stack frame of the caller.
I don't think that's right. C is compiled into an intermediate representation first. It's true that you can ask GCC etc. to generate assembly output, but it's not the default.
Just because there's an IR within the compiler doesn't mean there's no "assemble" stage. What do you think the "-pipe" flag to gcc is for? It pipes the compiler output into the assembler, rather than using a temporary .s file.
gcc has four main stages going from source to executable: preprocessor->compiler->assembler->linker.
Edit, for your convenience, gcc -save-temps example:
> [user@host /tmp/foo]$ ls
> f.c
> [user@host /tmp/foo]$ cat f.c
> #include <stdio.h>
>
> int main(int argc, char **argv)
> {
> puts("Hello world!");
>
> return 0;
> }
> [user@host /tmp/foo]$ gcc -o f -save-temps f.c
> [user@host /tmp/foo]$ ls -l
> total 48
> -rwxr-xr-x 1 user user 15416 Jan 13 16:50 f
> -rw-r--r-- 1 user user 91 Jan 13 16:49 f.c
> -rw-r--r-- 1 user user 17145 Jan 13 16:50 f.i
> -rw-r--r-- 1 user user 1496 Jan 13 16:50 f.o
> -rw-r--r-- 1 user user 515 Jan 13 16:50 f.s
> [user@host /tmp/foo]$ cat f.s
> .file "f.c"
> .text
> .section .rodata
> .LC0:
> .string "Hello world!"
> .text
> .globl main
> .type main, @function
> main:
> .LFB0:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> subq $16, %rsp
> movl %edi, -4(%rbp)
> movq %rsi, -16(%rbp)
> leaq .LC0(%rip), %rax
> movq %rax, %rdi
> call puts@PLT
> movl $0, %eax
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE0:
> .size main, .-main
> .ident "GCC: (GNU) 13.1.1 20230429"
> .section .note.GNU-stack,"",@progbits
> [user@host /tmp/foo]$ ./f
> Hello world!
> [user@host /tmp/foo]$
>it's so little used that i can't find the abi documentation, but gcc -c -mx32 does seem to generate code that passes arguments in registers, not on the stack, contrary to your assertion
edit: after enough digging, i found https://web.archive.org/web/20130902094821/https://sites.goo... linking to https://web.archive.org/web/20201015005434/https://3263a7b2-... but x32-abi-1.0.pdf seems to be missing from the archive and https://web.archive.org/web/*/https://sites.google.com/site/...* doesn't look at all promising
Splitting hairs perhaps, but the C compiler output is machine code, right? No reason to generate assembly along the way.
> Splitting hairs
> > generally
smh
https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_...