5 ms·

The Binary Language of Moisture Vaporators

21 points by geospeck 5y ago

Zababa 5y ago
I don't understand what "moisture vaporators" in that article refers to.
- Maursault 5y ago
  A moisture vaporator, also known as a vapor spire, was a device used on moisture farms to capture water from the atmosphere. Though stationary, they included programming that used a binary language to communicate with other equipment. Author employs moisture vaporators as tremendously clever reference to a notorious feature film and modern mythology.[1] [1] https://www.youtube.com/watch?v=eUH2_n8jE70&t=0m30s https://www.youtube.com/watch?v=eUH2_n8jE70&t=0m30s
  - Zababa 5y ago
    Thank you for the explanation.
- WalterBright 5y ago
  I always think of moisture vaporators when thinking about binary machine code.
WalterBright 5y ago
Walter here, AMA!
yusefnapora 5y ago
One of my first jobs was programming binary load lifters, very similar to your vaporators in most respects!
disas 5y ago
> But to build a compiler, you need to be able to see the output. A disassembler had to be built along with the compiler. Until very recently the dominant paradigm, at least for ahead-of-time compilers on Unix, was to emit textual assembler code and run a separate assembler on it behind the scenes. No disassembler needed, you can ask GCC or LLVM based compilers to just give you the intermediate data with -S. > But running obj2asm is a separate process, and the output is filled with all the boilerplate needed to create a proper object file. The boilerplate is rarely of interest, and I’m only interested in the generated code for a function. Sounds like a bug in obj2asm. GNU objdump, for example, has handy -d and -D flags for disassembling only the code for one or all symbols. > One would think that the way to do this would be to have the compiler generate the assembler source code, which would then be run through an assembler like MASM or gas to create the object file. I figured this would be slow and too much work. It was fast enough even for the very first C compilers... <checks calendar> 40 years ago. For actual compilations. Not to mention that when you as a human want to read the assembly code, it doesn't matter how "slow" the -S flag's output is. No matter how "Alpha" you are, the bottleneck will be you, the human. > Instead, the disassembler logic actually intercepts the binary data being written to the object file and disassembles it [...] I am not aware of any other compiler that does this in the same way. The HotSpot JVM has -XX:PrintAssembly and -XX:CompileCommand=ClassName.methodName flags that do this in the same way. Just like the author, I am not aware of any other, other compiler that does this in the same way. Because just like the author I haven't bothered to check. But if I had to bet, I would bet that all major just-in-time compilers do this in the same way.
- WalterBright 5y ago
  Yes, indeed, there are other ways to look at the assembler output. I've been doing that for 40 years. I heard the same things when D added builtin unittests, and builtin documentation generator. But we discovered that when things are builtin, and very convenient, it changes things dramatically. I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. > It was fast enough even for the very first C compilers... <checks calendar> 40 years ago. I actually did write a C compiler 40 years ago. Emitting assembler would mean another round trip to the floppy disk, and one might even have to swap floppies to do it. It would have been slowed to the point of making the compiler uncompetitive. Even if one forgave MASM for being miserably slow, as it had a linear symbol table and was multipass itself. Consider also that in those days, compilers did not run the linker. You compiled the code with one command, and linked with another. Mine (Datalight C) would do both in one step. After seeing that, every other compiler vendor did the same thing. Thanks for the tip on what Hotspot does. That seems to have been added starting with JDK8, after I had stopped working with Java. When I used it, one had to use the debugger.
  - disas 5y ago
    > I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. Try what? I know (and mentioned) two distinct ways of looking at the assembly code produced by my C compiler. It doesn't matter to me how -S is implemented because even if it's "slow" I am physically unable to count nanoseconds. I also know (and mentioned) that I know how to dump disassembly from HotSpot's memory. Yes, it's useful. > Consider also that in those days, compilers did not run the linker. You compiled the code with one command, and linked with another. Not sure what "those days" you mean. Running a single "cc" command and getting a single executable seems to have been well established by 1978: https://archive.org/details/TheCProgrammingLanguageFirstEdition/page/n13/mode/2up https://archive.org/details/TheCProgrammingLanguageFirstEdit... https://en.wikipedia.org/wiki/Datalight https://en.wikipedia.org/wiki/Datalight says that Datalight was founded in 1983; I have no way of telling whether you had started developing your compiler well before that.
StrictDabbler 5y ago
My job is literally speaking the binary language of cooling and dehumidification systems. I hadn't realized/noticed that Luke bought C-3PO to do my job. Not sure how to feel about it.

21 points by geospeck 5y ago

Zababa 5y ago

I don't understand what "moisture vaporators" in that article refers to.

Maursault 5y ago
A moisture vaporator, also known as a vapor spire, was a device used on moisture farms to capture water from the atmosphere. Though stationary, they included programming that used a binary language to communicate with other equipment. Author employs moisture vaporators as tremendously clever reference to a notorious feature film and modern mythology.[1] [1] https://www.youtube.com/watch?v=eUH2_n8jE70&t=0m30s https://www.youtube.com/watch?v=eUH2_n8jE70&t=0m30s
- Zababa 5y ago
  Thank you for the explanation.
WalterBright 5y ago
I always think of moisture vaporators when thinking about binary machine code.

WalterBright 5y ago

Walter here, AMA!

yusefnapora 5y ago

One of my first jobs was programming binary load lifters, very similar to your vaporators in most respects!

disas 5y ago

> But to build a compiler, you need to be able to see the output. A disassembler had to be built along with the compiler. Until very recently the dominant paradigm, at least for ahead-of-time compilers on Unix, was to emit textual assembler code and run a separate assembler on it behind the scenes. No disassembler needed, you can ask GCC or LLVM based compilers to just give you the intermediate data with -S. > But running obj2asm is a separate process, and the output is filled with all the boilerplate needed to create a proper object file. The boilerplate is rarely of interest, and I’m only interested in the generated code for a function. Sounds like a bug in obj2asm. GNU objdump, for example, has handy -d and -D flags for disassembling only the code for one or all symbols. > One would think that the way to do this would be to have the compiler generate the assembler source code, which would then be run through an assembler like MASM or gas to create the object file. I figured this would be slow and too much work. It was fast enough even for the very first C compilers... <checks calendar> 40 years ago. For actual compilations. Not to mention that when you as a human want to read the assembly code, it doesn't matter how "slow" the -S flag's output is. No matter how "Alpha" you are, the bottleneck will be you, the human. > Instead, the disassembler logic actually intercepts the binary data being written to the object file and disassembles it [...] I am not aware of any other compiler that does this in the same way. The HotSpot JVM has -XX:PrintAssembly and -XX:CompileCommand=ClassName.methodName flags that do this in the same way. Just like the author, I am not aware of any other, other compiler that does this in the same way. Because just like the author I haven't bothered to check. But if I had to bet, I would bet that all major just-in-time compilers do this in the same way.

WalterBright 5y ago
Yes, indeed, there are other ways to look at the assembler output. I've been doing that for 40 years. I heard the same things when D added builtin unittests, and builtin documentation generator. But we discovered that when things are builtin, and very convenient, it changes things dramatically. I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. > It was fast enough even for the very first C compilers... <checks calendar> 40 years ago. I actually did write a C compiler 40 years ago. Emitting assembler would mean another round trip to the floppy disk, and one might even have to swap floppies to do it. It would have been slowed to the point of making the compiler uncompetitive. Even if one forgave MASM for being miserably slow, as it had a linear symbol table and was multipass itself. Consider also that in those days, compilers did not run the linker. You compiled the code with one command, and linked with another. Mine (Datalight C) would do both in one step. After seeing that, every other compiler vendor did the same thing. Thanks for the tip on what Hotspot does. That seems to have been added starting with JDK8, after I had stopped working with Java. When I used it, one had to use the debugger.
- disas 5y ago
  > I suggest you try it before dismissing it. It's changed the way I work, and has started changing the way others do, too. Try what? I know (and mentioned) two distinct ways of looking at the assembly code produced by my C compiler. It doesn't matter to me how -S is implemented because even if it's "slow" I am physically unable to count nanoseconds. I also know (and mentioned) that I know how to dump disassembly from HotSpot's memory. Yes, it's useful. > Consider also that in those days, compilers did not run the linker. You compiled the code with one command, and linked with another. Not sure what "those days" you mean. Running a single "cc" command and getting a single executable seems to have been well established by 1978: https://archive.org/details/TheCProgrammingLanguageFirstEdition/page/n13/mode/2up https://archive.org/details/TheCProgrammingLanguageFirstEdit... https://en.wikipedia.org/wiki/Datalight https://en.wikipedia.org/wiki/Datalight says that Datalight was founded in 1983; I have no way of telling whether you had started developing your compiler well before that.

StrictDabbler 5y ago

My job is literally speaking the binary language of cooling and dehumidification systems. I hadn't realized/noticed that Luke bought C-3PO to do my job. Not sure how to feel about it.