7 ms·
Can you tell an assembly language when you see one?
- Flocular 5y agoFor 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"
- souprock 5y agoYes...? I'm disputing the characterization of WebAssembly as assembly. There does not exist a CPU which runs a trivial translation of WebAssembly.
- cmeacham98 5y agoWhat 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 https://github.com/Storyyeller/Krakatau 2: https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor
- userbinator 5y agohttps://en.wikipedia.org/wiki/Jazelle 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...)
- dnautics 5y agoI 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.
- dtech 5y agoI don't think that's a fair definition. If such a CPU could be reasonably made, you could still call it assembly.
- FatalLogic 5y agoBut it hasn't been made. Isn't that the point? Assembly maps very closely to actual hardware instructions/opcodes
- pjmlp 5y agoNot on x86 it doesn't.
- FatalLogic 5y agoWell, nonetheless, it's the lowest level you can code at, isn't it?
- pjmlp 5y agoSame 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.
- FatalLogic 5y agoThis is interesting, thanks, but I don't understand how it supports the refutation you made about x86, which is what I was responding to
- junon 5y agoMost 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".
- erk__ 5y agoThere 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 https://datamuseum.dk/wiki/Rational/R1000s400
- GuB-42 5y agoIt 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.
- junon 5y agoNo, because processors don't run ada directly.
- hvdijk 5y agoIt'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.
- pjmlp 5y agoWell, 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.
- userbinator 5y agoLong-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).
- aidenn0 5y agoI 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.
- pjmlp 5y agoBack 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.
- hyperpallium2 5y agoThis 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.
- krallja 5y agowhat does this line of ForwardCom mean ``` uint64 r0 > >= 1 ``` If there were no space between > and >= it would be ordinary looking C-minus-semicolons.
- deleted 5y ago[deleted]
- JI00912 5y agoPerson 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.
- LudwigNagasena 5y agoEven the same person can use different definitions depending on context.
- JI00912 5y agoYes. People even argue with themselves while projecting on other people.
- fao_ 5y ago> 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!
- axguscbklp 5y agoI 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.
- axguscbklp 5y agoNow 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.
- codeflo 5y agoIs 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.
- archi42 5y agoThere 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/ https://developer.arm.com/documentation/ddi0487/ga/ by clicking "Download").
- codeflo 5y agoI 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.
- archi42 5y agoAbsolutely. 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.
- saagarjha 5y agoFor those looking for more amusing assembly syntaxes, I present Blackfin, which looks almost HLL-like at first glance: https://github.com/torvalds/linux/blob/b8c9c8f0190f4004d3d4364edb2dea5978dfc824/arch/blackfin/lib/memcmp.S 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.
- pjmlp 5y agoAs 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.
- FatalLogic 5y agoMy 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
- CodeArtisan 5y agoAssembly 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).
- FatalLogic 5y agoI 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.
- pjmlp 5y agoThe 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.