• pranaless@beehaw.org
      link
      fedilink
      arrow-up
      31
      ·
      1 year ago
      use std::process::Command;
      
      fn main() {
          Command::new("sh")
              .arg("-c")
              .arg("echo Hello World!")
              .spawn()
              .unwrap();
      }
      

      Like this?

      • 30p87@feddit.de
        link
        fedilink
        arrow-up
        10
        ·
        1 year ago

        No, more like

        use std::process::Command; fn main() { Command::new("sh").arg("-c").arg("echo Hello World!").spawn().unwrap(); }
        

        .
        Just a little bit shorter, as it seems /s

          • pranaless@beehaw.org
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Yes and no. While coreutils does provide an echo binary, shells also have a built-in for optimisation purposes.

            At first I had the code calling the binary directly, but then changed it to spawning a shell (and so using the builtin). It’s very cursed either way.

  • umbraroze@kbin.social
    link
    fedilink
    arrow-up
    20
    ·
    1 year ago

    Oh you fancy PC people and your fancy syscall instruction.

    I still don’t know why I could remember jsr $ab1e. I didn’t even write that much assembly.

  • r00ty@kbin.life
    link
    fedilink
    arrow-up
    19
    ·
    1 year ago

    Or, you could just go the whole hog. Create your own simple CPU emulator, design a basic 8bitesque CPU, give it an output port that is the console, and load up some basic ASM to cycle through Hello World to the console port.

  • Speiser0@feddit.de
    link
    fedilink
    arrow-up
    15
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Definitely left. Right one won’t be optimized. (And there are so many some mistakes in your inline asm…)

      • Speiser0@feddit.de
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        Mostly the missing listing of clobbered registers. Other than that it’s mostly just that you’re doing useless things, like manually putting the stuff into the registers instead of letting the compiler do it, and the useless push and pop. And the loop is obviously not needed and would hurt performance if you do every write like that.

        asm!(
        "syscall",
        in("rax") 1,
        in("rdi") 1,
        in("rsi") text_ptr,
        in("rdx") text_size,
        
        )
        

        (“so many” was inappropriate, sorry.)

  • nonearther
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    3
    ·
    edit-2
    1 year ago

    console.log(“Hello World!”)

  • DNOS@reddthat.com
    link
    fedilink
    arrow-up
    5
    ·
    edit-2
    1 year ago

    Ec Emm this side is the best one …

    ++++++++[< +++++++++>-]<. ++++[<+++++++>-]<+. +++++++… +++.

    ++++++[<+++++++>-]<++. ------------. ++++++[<+++++++++>-]<+. <. +++. ------. --------.

    ++++[<++++++++>-]<+.

  • raubarno@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    Why do you call write() for every char? You can always just pass a pointer with its length.

    • AMDIsOurLord
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      Well, the GNU version does more and is more documented. The Plan9 code is frankly shitC, even for 1980z

      But this monstrosity is something else

      • 257m@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Plan 9 does the job. GNU is better for the end user. But if I had to maintain that stuff I would definitely want to maintain the Plan 9 code and not the GNU code.

    • rhpp@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      reddit image linking is broken?

      Well you didn’t link to a reddit image, you linked to Google image search result page which is not an image.