It Isn’t WebAssembly, But It Is Assembly In Your Browser

You might think assembly language on a PC is passe. After all, we have a host of efficient high-level languages and plenty of resources. But there are times you want to use assembly for some reason. Even if you don’t, the art of writing assembly language is very satisfying for some people — like an intricate logic puzzle. Getting your assembly language fix on a microcontroller is usually pretty simple, but on a PC there are a lot of hoops to jump. So why not use your browser? That’s the point of this snazzy 8086 assembler and emulator that runs in your browser. Actually, it is not native to the browser, but thanks to WebAssembly, it works fine there, too.

No need to set up strange operating system environments or link to an executable file format. Just write some code, watch it run, and examine all the resulting registers. You can do things using BIOS interrupts, though, so if you want to write to the screen or whatnot, you can do that, too.

The emulation isn’t very fast, but if you are single-stepping or watching, that’s not a bad thing. It does mean you may want to adjust your timing loops, though. We didn’t test our theory, but we expect this is only real mode 8086 emulation because we don’t see any protected mode registers. That’s not a problem, though. For a learning tool, you’d probably want to stick with real mode, anyway. The GitHub page has many examples, ranging from a sort to factorials. Just the kind of programs you want for learning about the language.

Why not learn on any of a number of other simulated processors? The 8086 architecture is still dominant, and even though x86_64 isn’t exactly the same, there is a lot of commonalities. Besides, you have to pretend to be an 8086, at least through part of the boot sequence.

If you’d rather compile “real” programs, it isn’t that hard. There are some excellent tutorials available, too.

18 thoughts on “It Isn’t WebAssembly, But It Is Assembly In Your Browser

  1. Yeah, it’s going to be real mode because the 8086 didn’t have protected mode. That wasn’t introduced until the 80286, and there was no way to switch back to real mode without a major hardware kludge until the 80386.

  2. 8086 sure is not “dominant” 32 bit Intel has been removed from just about every Linux distribution, now it lives with other dead architectures like the cray1 and the 6502.

    Good riddance and good bye to a slapped together arch that is very compiler unfriendly it’s a great lesson in how not to design a processor.

  3. pff…
    @X each to their own.
    BUT your ‘compiler’ you talk about is an assembler (we are talking about asm here), so wrong terminology to begin with. I feel as though you enjoyed your soapbox shout with little knowledge and appreciation for history.
    I so much wanna say, why didnt you do it better?

    I still run x32 XP and dabble in 80×86 asm – and everything runs beautifully in its native environment.
    Heck, I still fiddle with z80 asm.

    Im one of those few rare people that wished that the computing world was still back in 2002.

    1. I am referring to compilers in general, the lack of general purpose registers means that any compiler must keep variables in RAM. The lack of advanced addressing modes means you have to do more math yourself to calculate that pointer offset.

      Yeah we already had better architectures, Power and SPARC are much better places to run your C code. They both have lots of registers and the addressing modes you need to access array and structure elements quickly. In addition they are much more pleasant for hand coded assembler.

      Sure you can dabble around on any processor and it is indeed great fun but if you choose something current then you can also enhance your job opportunities. Especially today there is great demand for folks who can stuff in that 3 line assembler hack and get 20 x speedup in an inner loop. This is a rare talent and you can make big $$$.

    2. In some ways I do too. I hear you. Those were fun days. I remember a writing serial (rs-232) drivers and graphic subroutines in x86. Fun times :) . I still have a shelf full of x86 (16 bit and 32 bit) books (you know … what we used before the internet) that helped me along. I worked a bit with z80 assembly at work too. We had a whole substation and communications SCADA RTU application written in z80 assembly code — quite a long listing. I didn’t write the original code, just helped maintain it over time. Don’t recall the assembler application vendor, but seems like the executable was called Z80.EXE . Also, writing bootstrap code for our custom 68xxx boards too. Those were the days. C and assembly. All you needed to get the job done.

      Now, I am content with playing with ARM (32 and 64) assembly at home… to get my assembly ‘programming fix’ using RPIs and PICOs. There is something about programming close to the bare metal ( as reasonably possible ) and seeing your program do something.

      That said, I don’t want to go back to set data switches, toggle load, set data switches, toggle load, …. I am not patient or exacting enough for that level of programming…. But do appreciate the guys/gals that could do that sort of programming for a career.

    3. 2002, when phones were just smart enough, but no smarter. When well-crafted blogs and forums taught us how to do stuff, instead of clickbait videos. When computers could play HD video, but the web wasn’t flooded with terabytes of huge video files for no justification. When megabit internet was plenty, because the web wasn’t so bloated.

      Yeah, I miss those times too.

  4. I started with IBM 360 punch cards in FORTRAN, went punch tape in PDP-8 asm, then 8080 asm, 6800 asm, and finally 6809 asm on audio cassette tape on my home TRS80 Color Computer — the most elegant processor architecture I’ve ever run across. Now it’s all in python, but I look back fondly to my asm days.

Leave a Reply to daveCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.