3 ms·

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 ta

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

nneonneo 3y ago
It says that the DB is SQLite, so I presume they’re just linking to the SQLite libraries.
atdt 3y ago
It's less complicated than you might think. You call into SQLite C library functions using C calling conventions. Here's the relevant code: https://asm32.info/fossil/asmbb/file?name=source/sqlite3.asm&ci=tip https://asm32.info/fossil/asmbb/file?name=source/sqlite3.asm...
- andoando 3y ago
  How about for setting up a server and serving http requests / establishing web sockets? If it’s just a bunch of calling C code then I have to ask which part of this is actually assembly
  - wavemode 3y ago
    To be fair, from that perspective every backend web application in every language is really just "calling C code".
    - eterm 3y ago
      That's overly simplistic and untrue. If you write a C# / .Net program you're not "just calling C code", you're not calling C at all.
      - mldbk 3y ago
        but then your runtime VM calls C :)
      - tsm212 3y ago
        But the CLR is written c, c++ and assembly which is what runs c#. Also the syscalls that run down the chain are also written in c, c++ etc.
        struant 3y ago
        That is just the runtime. That is smaller of fraction of what is going on when your programs execute than you think. 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).
  - wruza 3y ago
    You can ask the same about e.g. Pascal, Python and Javascript, because all of them just make a bunch of C calls at the end of the day and can’t use NIC ports directly.
  - duped 3y ago
    To do this in assembler you write raw syscalls to bind to open the TCP stream and then accept to handle incoming connections, possibly with fork or clone3 to spawn a process/thread to handle the new connection. None of that requires C programming. HTTP is "just" some text parsing on top of read/write calls to the file descriptor returned by accept. Web sockets are "just" some connection logic on top of HTTP. 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.
  - deaddodo 3y ago
    Well, you see, most OSes today aren't written in ASM. Their native libraries are C, so you have to interface with those libraries if you want to utilize them and their features. 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.
pengaru 3y ago
C is generally first compiled into assembly anyways. 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.
- nineteen999 3y ago
  > x32 was more pleasant by far, since it only used the stack 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 ... https://en.wikipedia.org/wiki/X86_calling_conventions https://en.wikipedia.org/wiki/X86_calling_conventions
  - pengaru 3y ago
    Apologies, my experience is SysV-centric for amd64, as described here[0] under the Parameter Passing section, which is a clustrfuck compared to the simplicity of the 386 SysV ABI as described here[1]: > 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. Both links were found @ https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI [0] https://www.uclibc.org/docs/psABI-x86_64.pdf https://www.uclibc.org/docs/psABI-x86_64.pdf [1] https://www.sco.com/developers/devspecs/abi386-4.pdf https://www.sco.com/developers/devspecs/abi386-4.pdf
- kristianp 3y ago
  > C is generally first compiled into assembly anyways. 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.

nneonneo 3y ago

It says that the DB is SQLite, so I presume they’re just linking to the SQLite libraries.

atdt 3y ago

It's less complicated than you might think. You call into SQLite C library functions using C calling conventions. Here's the relevant code: https://asm32.info/fossil/asmbb/file?name=source/sqlite3.asm&ci=tip https://asm32.info/fossil/asmbb/file?name=source/sqlite3.asm...

andoando 3y ago
How about for setting up a server and serving http requests / establishing web sockets? If it’s just a bunch of calling C code then I have to ask which part of this is actually assembly
- wavemode 3y ago
  To be fair, from that perspective every backend web application in every language is really just "calling C code".
  - eterm 3y ago
    That's overly simplistic and untrue. If you write a C# / .Net program you're not "just calling C code", you're not calling C at all.
    - mldbk 3y ago
      but then your runtime VM calls C :)
    - tsm212 3y ago
      But the CLR is written c, c++ and assembly which is what runs c#. Also the syscalls that run down the chain are also written in c, c++ etc.
      - struant 3y ago
        That is just the runtime. That is smaller of fraction of what is going on when your programs execute than you think. 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).
- wruza 3y ago
  You can ask the same about e.g. Pascal, Python and Javascript, because all of them just make a bunch of C calls at the end of the day and can’t use NIC ports directly.
- duped 3y ago
  To do this in assembler you write raw syscalls to bind to open the TCP stream and then accept to handle incoming connections, possibly with fork or clone3 to spawn a process/thread to handle the new connection. None of that requires C programming. HTTP is "just" some text parsing on top of read/write calls to the file descriptor returned by accept. Web sockets are "just" some connection logic on top of HTTP. 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.
- deaddodo 3y ago
  Well, you see, most OSes today aren't written in ASM. Their native libraries are C, so you have to interface with those libraries if you want to utilize them and their features. 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.

pengaru 3y ago

C is generally first compiled into assembly anyways. 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.

nineteen999 3y ago
> x32 was more pleasant by far, since it only used the stack 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 ... https://en.wikipedia.org/wiki/X86_calling_conventions https://en.wikipedia.org/wiki/X86_calling_conventions
- pengaru 3y ago
  Apologies, my experience is SysV-centric for amd64, as described here[0] under the Parameter Passing section, which is a clustrfuck compared to the simplicity of the 386 SysV ABI as described here[1]: > 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. Both links were found @ https://wiki.osdev.org/System_V_ABI https://wiki.osdev.org/System_V_ABI [0] https://www.uclibc.org/docs/psABI-x86_64.pdf https://www.uclibc.org/docs/psABI-x86_64.pdf [1] https://www.sco.com/developers/devspecs/abi386-4.pdf https://www.sco.com/developers/devspecs/abi386-4.pdf
kristianp 3y ago
> C is generally first compiled into assembly anyways. 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.