Comment by makmanalp | Hacker News Reader

Comment by makmanalp | Hacker News Reader

Pretty neat! It's awesome how assembly these days is reasonably high level:

https://github.com/nemasu/asmttpd/blob/master/http.asm

It dawns on me why we couldn't have shortcuts for several patterns that show up everywhere:

- mov, mov, mov then call/syscall could just be written as call(arg, arg, arg) since it's not that difficult to figure out which argument needs to go to which register if there was a defined order of arguments.

- push push push push <function body> pop pop pop pop <ret> could just be a define really. I realize that there are cases where you wouldn't necessarily do that, but that seems to be the minority. The compiler could just figure out what registers you use in the routine and push / pop those. If you want to keep a register, there could be added syntax for that.

It seems in both of these cases the language optimizes for simplicity and flexibility, ignoring the common case. Neither of these strike me as situations where introducing the abstraction would require a lot of compiler "magic" to guess and optimize. It's almost just string replacement.

Then again, you could just write all this in C and let the compiler figure it out. Interesting stuff!

> It's awesome how assembly these days is reasonably high level:

There were macro assemblers already available in the 80's!

This. Microsoft MASM is the canonical example of one.

Born in 1981, still being updated today:

http://en.wikipedia.org/wiki/Microsoft_Macro_Assembler

In my OS/architecture class we used a textbook whose author had piled on so much macro assembling on top of SPARC asm (macros all in m4, naturally) that he in effect was writing the book using a personal high-level language constructed out of gobs of m4. Like the bizarro-world version of personalized language construction in Lisp-land...

Was this book (the first review complains about the same thing): http://www.amazon.com/gp/product/0130255963/ref=as_li_ss_tl?...

I used this book for OS/architecture class as well.

I think the use of m4 needlessly complicated the material.

Indeed, I pretty much learned programming on the C64 using Turbo Assembler which had macro functionality.

AFAIK the Turbo Assembler was producing x86 bytecode, how would that work?

http://turbo.style64.org/about-the-turbo-assembler-homepage

"Turbo Assembler is a native c64 assembler which was introduced in 1985 by the German company, Omikron."

> x86 bytecode

What?!

I guess he's talking about Borland's Turbo Assembler that was coming with Turbo Pascal: http://en.wikipedia.org/wiki/Turbo_Assembler

My remark was because the OP used bytecode to describe assembly opcodes.

The usage is nonstandard, but it provides an interesting perspective. What if he was planning to run the X86 code on a virtual CPU, is his usage then correct? Does the nature of compiled code change if it is executing on a "real" machine instead of a virtual one?

I would say yes, given that some bytecode instruction sets make a CISC processor look like a RISC one.

You must be confusing Turbo Assembler on the Commodore 64 with something else, the C64 used an 8-bit cpu called 6510

I learned assembly on the Atari 8-bit (like the C64 and AII, all of which used a variant of the Motorola 6502) which had an assembler named MAC/65. MAC, of course, was short for macro. This was in the early 80's also. Good times.

http://en.wikipedia.org/wiki/MAC/65

Try the 60's.

Also CISC instruction sets (VAX, 68k) were already pretty high-level.

TASM from Borland had bunch of macros/shortcut keywords for the patterns you describe. There's dozens of library files to do similar things in MASM as well. mammon_ had written a bunch of macros [1] that do same thing for NASM. See how he exploits NASM's preprocessor for this in his "Extending NASM" article in the Assembly Language Journal, Feb/Mar 1998, Issue 3. He also demonstrates how do all the control structures in NASM's preprocessor (for, if, switch/case, while, do/while, etc.).

[1] http://mammon.github.io/Text/nasm_apj.txt

If you or anyone is looking for something which takes care of a lot of the entry and exits to functions I would suggest they look x264's x86inc.asm [1]. It was designed for using SIMD in DSP functions not for writing whole programs but I don't think it would get in your way of doing that.

Plus it is BSD licensed for those that hate the GPL.

[1] http://git.videolan.org/?p=x264.git;a=blob;f=common/x86/x86i...

Most decent assemblers supports macros, some of them fairly complicated.

And there is Randall Hyde's High Level Assembly: http://www.plantation-productions.com/Webster/

Reply on news.ycombinator.com