Hacker News Reader

Comment by userbinator | Hacker News Reader

Long-time Asm programmer here, mostly experienced with x86 but also did Z80, 8051, some ARM and MIPS, with some brief exposure to JVM bytecode, .NET IL, and ActionScript. I don't think ForwardCom counts, and WASM is a borderline edge-case due to its syntax. IMHO the defining characteristic of Asm is being able to specify the exact machine instructions (even if the ISA is not a hardware one), so things like the .NET IL and Java bytecode would count. The one-instruction-per-line format is also common but not obligatory (see the somewhat infamous RosAsm).

View on HN

I kind of feel like if WASM and JVM are assembly languages then a lot of Forth implementations (also being low-level stack languages) would qualify as assembly as well.

Back in the day, there used to exist hardware where Forth was the lowest that you could go, so yes it can be considered Assembly on some hardware.

Back in the day == 10 years ago?

Green Arrays Inc was producing forthchips in 2011.

I remember stuff like FigForth being shipped on eproms, that is what back in the day means to me.

I don't follow Forth.

I think I'd want to extend your definition a bit. I do think that it's reasonable to target a virtual machine with a so-called assembly language, however an assembly language must have an unambiguous bidirectional mapping between the target binary code and the assembly language. I'd also explicitly rule out any language that abstracts away things like which registers you're targeting, even if it does so in a deterministic fashion, as it removes control over which instructions you're actually emitting.

That is not to say that you can't have macros in an assembly language. While you can't unambiguously recover any macros (or label names, for that matter) used when generating assembly language from the binary output, you can still unambiguously recover some sort of assembly which can be used to generate an identical binary output, excepting any junk your particular platform does that prevents reproducible builds such as embedding timestamps.

> assembly language must have an unambiguous bidirectional mapping between the target binary code and the assembly language.

This isn’t true for many CPU assembly languages, though. For example, the x86 instruction `add eax, ecx` can be assembled to either `01 c8` or `03 c1`.

> you can still unambiguously recover some sort of assembly which can be used to generate an identical binary output

If your binary contains `01 c8`, information is lost when that’s disassembled to `add eax, ecx` and there’s no guarantee that a newly assembled binary won’t contain `03 c1` in its place.

Hm, yeah I hadn't considered the possibility of the machine itself having aliased instructions. That's some interesting info, thank you.

This definition implies every interpreted language is an assembly language, with the interpreter as the "machine"... something more is needed.

Also, while C might not be an assembly language... it combines the power and performance of assembly language with the flexibility and ease-of-use of assembly language.

Lol. C is actually a lot more convenient to program in than assembly, though, and it is abstracted away from the hardware enough to be largely platform agnostic when you aren't writing low level peripheral code.

Reply on news.ycombinator.com