Can you tell an assembly language when you see one? | Hacker News Reader

Can you tell an assembly language when you see one?

wordsandbuttons.online

68 pointsokaleniuk53 comments

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).

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.

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.

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.

Yes...? I'm disputing the characterization of WebAssembly as assembly. There does not exist a CPU which runs a trivial translation of WebAssembly.

What about the JVM? Tools for modifying java bytecode call themselves "assemblers" and "disassemblers"[1]. There have been previous attempts at a physical CPU that runs JVM bytecode[2] but to my knowledge none exist for the current version.

1: https://github.com/Storyyeller/Krakatau

2: https://en.wikipedia.org/wiki/Java_processor

https://en.wikipedia.org/wiki/Jazelle is one notable implementation, unfortunately details are proprietary and there doesn't seem to be much in the way of RE attempts (you'd think more people would be curious about finding out how a completely undocumented instruction set extension works...)

I feel similarly about the erlang vm bytecode assembly. When you read it it helps to know something about true assembly languages, as you're mostly manipulating registers and sending them to operands.

I don't think that's a fair definition. If such a CPU could be reasonably made, you could still call it assembly.

But it hasn't been made. Isn't that the point? Assembly maps very closely to actual hardware instructions/opcodes

Not on x86 it doesn't.

Well, nonetheless, it's the lowest level you can code at, isn't it?

Same applies to any bytecode format, when an hardware implementation for it happens to exist.

It was how Xerox PARC workstations worked, the bytecode of Interlisp-D, Mesa, Mesa/Cedar, Smalltalk worked, with microcode interpreter loaded on boot for them.

How Lillith (Modula-2) and Cedar (Oberon) workstations worked, with hardware implementation of their bytecode formats.

How some Java CPUs like Jazelle and JavaOS worked.

How Pascal USCD worked on Constellation OS by Corvus Systems.

How Burroughs B5500 mainframes worked, with ESPOL/NEWP intrinsics, still being shipped by Unisys nowadays on a completely unrelated hardware form.

I certainly can dig out a couple of other examples.

This is interesting, thanks, but I don't understand how it supports the refutation you made about x86, which is what I was responding to

Modern x86 is just bytecode for a microcode only Intel has the tooling available.

I understand that. Then this is probably just a disagreement about the definition of 'Assembly'.

I define Assembly as the lowest level that is user-accessible. I think you would say that's a rather arbitrary division in the case of x86, when there is a sophisticated microcode language underneath it?

Yes, history is full of bytecode formats at any given point have gotten hardware implementation for them.

In some platforms they are even the only kind of format for executables and raw Assembly is forbidden to any userspace application, e.g. IBM i (nee AS/400) TIMI environment, where raw machine code is only available to the kernel, in the POSIX subsystem or special binaries produced via the Metal C compiler.

Person using definition A: Yes it is!

Person using definition B: No it isn't!

---

Actual situation: Different people using the same word to refer to different things.

Even the same person can use different definitions depending on context.

Yes. People even argue with themselves while projecting on other people.

For me assembly is formatted version of what my hardware can parse without further abstraction. Any other way everything is assembly. I can find an assembly C-compiler && I can find a C-python compiler == python is assembly... But I would find the challenge interesting if you're asking "how advanced of instructions can our hardware handle these days"

Is macro assembly really assembly though? I clicked no because I claim that there’s a continuum of expressiveness between a macro assembler and a C compiler, which makes it hard to draw a line. This is debatable of course, and I was hoping the article would go into some of this. Instead, the analysis seems to stop at “if it’s called assembly, it is assembly”, unfortunately.

Edit: I suggest that as a necessary condition for something to be assembly,

disassemble(assemble(x)) = x,

modulo comments and label names.

There is another commenter who kind of thinks that this should hold, but I've got to disappoint either of you: Most ISAs specify some pseudo ops, so might get something like

  disassemble(assemble("nop")) == "add r0, 0"

I think that's how v850 or tricore do it. Than there is ARM, for which the v8.6 ISA manual casually contains the term "This instruction is an alias of" 115 times. (I checked the rev. F PDF, you can get the rev. G PDF at https://developer.arm.com/documentation/ddi0487/ga/ by clicking "Download").

I hope we agree that alternative mnemonics don't change anything essential about the code, so the equation "kind of" still holds. You have a point that it's hard to formulate this precisely.

Absolutely. I tried, but gave up and decided to spent my saturday morning with the familiy instead ;-)

I think a huge problem is how it is easy to mix up assembly that gets "processed" to /machine/ instructions with another kind of assembly that gets "processed" to VM ops. Which then get compiled again (usually JIT) before being executed.

ILAsm is a nice example for that: It's some kind of assembly language, and you could probably go right down to x86 instructions (at least with little change). But you'll never do that. Simply because it is a stack language; and while you can produce e.g. x86 opcodes that "do the right thing", the whole stack traffic will kill performance. Instead, the VM will push the opcode stream through a (I guess JIT?) compiler: Small functions will be inlined, others will get a prologe and epiloge, parameters and return values are arranged according to the ABI's calling conventions. And then there will be all the usual register allocation stuff. [edit] And a lot of other magic. [/edit] Still, the original input is pretty much an assembly language.

For those looking for more amusing assembly syntaxes, I present Blackfin, which looks almost HLL-like at first glance: https://github.com/torvalds/linux/blob/b8c9c8f0190f4004d3d43.... In terms of expressiveness it’s about the same as any other CPU-level assembly, but the syntax is pretty wild.

> This is GNU SmallTalk — one of the most influential early OOP languages. It does have slightly unconventional syntax, but it has nothing in common with assembly programming at all. If anything, it is as far from low-level platform-dependent programming as it could be.

That's not-quite-correct, since the Smalltalk-80 implementation manual sitting on my shelf explicitly details the bytecode that compiles to. It's not "as far from low-level programming" as can be, it compiles directly to a bytecode!

My impression is that WebAssembly was so named because the developers wanted a cool name that indicated it was low level and in a sense akin to an assembly language, not because it was actually the same thing as assembly.

But, inadvertently, such influential projects gradually warp the definition of the word 'assembly' or 'assembler' away from what it traditionally was: the most close to the metal and minimal abstraction from hardware.

Perhaps that's OK? But it does cause some arguments

Assembly is the textual representation of an instruction set meant to be executed by a machine. That machine being abstract (turing), implemented in software (virtual) or hardware shouldn't be relevant. An alternative to assembly is lambda calculus which is not executed but evalued (everything is an expression, unlike assembly where everything is a statement).

I feel that extending the definition of 'a machine' to include abstract or virtual machines is an extension of the original meaning of 'Assembly' - it's not how the word was originally used.

But it seems like it could be a better definition, as it gets closer to the essential meaning.

The original version was actually bytecode as you can see in many 50's and 60's papers, because when computing switched to micro-electronics most CPUs were micro-coded, this was one of the arguments of RISC against CISC, no micro-coded needed and all instructions should be implemented as hardware gates.

After all these gates it turns out that while RISC had some nice ideas, the flexibility of microcoded CPUs won the war anyway, and nowadays stuff like FPGAs makes it even more flexible than traditional microcode languages.

I might be off from the standard definition, but normally I think of "assembly language" as meaning a language that can be transformed to machine code by using a simple 1-to-1 substitution. Using this definition, there is no way to tell an assembly language when you see one unless you know every machine code that the question could possibly have in mind.

That said, probably most of the time when people say "assembly language" their definition is not as strict as mine.

Now that I think of it, I do think of it as 1-to-1 substitution, but it is not completely trivial - when transforming to machine code, you do generally have to keep track of where in the code you are to know whether to try to transform an assembly language token into a machine language opcode or into some other sort of machine language value.

Most of the "this is assembly" is not what I'd consider assembly. Is compiled Lua bytecode "assembly"? If your answer is "no" (as is mine) then neither are java class files, C# IR, webassembly bytecode or most of what else this article calls "assembly".

It's .NET IR, not C# IR, but I agree. If the bytecode is not executed directly by the CPU, if there's a separate translation layer to convert that to machine code, then a user-friendly presentation of the bytecode is not an assembly language.

Well, there is always the option to just pick a FPGA language and write an hardware implementation for them.

Most mainframes, like those from Xerox PARC, don't have any kind of Assembly, the first step of booting was to load the corresponding microcode execution engine.

Isn't x86 assembly not directly executed by the CPU? IIRC it's turned into microcode instructions. I could be wrong though

Yes

It’s turned into uops... by the CPU.

(And most instructions correspond to 1 or a few uops in a straightforward way).

The ASM (text) that you write is converted into machine code, and that is directly accepted and decoded by the hardware (which may turn it into Mops and uops internally, but that's an implementation detail!)

There is another fun one wich is Ada, there is a hardware implementation of it. So is it a assembly language? https://datamuseum.dk/wiki/Rational/R1000s400

It doesn't look like a hardware implementation of ADA, more like a computer optimized for running ADA programs.

That is, you still need a compiler, with optimization, register/stack allocation, etc... before you start outputting machine code that is run by the hardware. However all the tricky parts of ADA, the task model in particular, are implemented in hardware.

So it doesn't make ADA an assembly language.

Maybe FORTH and LISP could be considered assembly in some circumstances. I don't know enough about these and their machine implementation to be sure but it looks like there can be a 1:1 relationship between these languages and machine code.

No, because processors don't run ada directly.

As for C like Assembly language, Texas Instruments has some DSP Assembly that is similar to C syntax as written in SSA form, I just can't recall the name any longer.

what does this line of ForwardCom mean

``` uint64 r0 > >= 1 ```

If there were no space between > and >= it would be ordinary looking C-minus-semicolons.

I would say the space between "> >=" is a typo, and should be ">>=", which would mean shift right.

Seems right

Reply on news.ycombinator.com