Why write in assembler

I mean will it be useless or not? I am also wondering why they are written in C? People have written assemblers in machine code. They've also written then in assembly language--often a subset of the language they translate themselves, so they start with a simple "bootstrap" version of the assembler, then add features to it as they need them for the assembler itself.

However, none of this is particularly a necessity. In the end, an assembler is a usually fairly simple translation program. It takes in a file in one text format, and writes out a file in another usually an object file format. The fact that the text that's input represents machine instructions in a textual format and the result represents the same instructions in binary format doesn't make much difference to the language that's used to implement the assembler--in fact, even higher languages than C such as SNOBOL and Python can work quite nicely--I fairly recently worked on an assembler written in Python, and it worked pretty well for the job.

As far as how you bootstrap things initially: typically on another machine that has decent development tools and such. If you're developing new hardware, you usually start by writing a simulator or at least emulator for the new machine anyway, so at first you're building and running the code on some host system in any case. You use the tools to handle that task that are best for that task.

There is nothing special about writing an assembler; there is no reason at all not to write it in a high level language. Assembly language is actually totally unsuitable for a task like this. The cases where you would reasonably use assembly language are very, very rare. Only when you need to do things that cannot be expressed in a higher level language. Assembly is essentially a mnemonic for machine code; each opcode in the machine language is given an assembly mnemonic i.

This makes assembler's rather simple n. The first assembler was written and translated by hand likely on paper into machine code. A better version is written and assembled with the hand 'assembled' assembler, new features are added this way.

Compilers for new languages can be built this way; in the past it was common for compilers to output assembly, and use an assembler for their back end! Bootstrapping is the process of getting a tool-chain on a new architecture. If one was developing a new CPU with a new or existing machine language, a simulator is usually necessary for testing; i.

Then find bugs, fix bugs, repeat. Among the reasons to write an assembler in C or any other higher level language are all the reasons you might use to justify writing any other program in that higher level language.

Chief among those in this case are probably portability and usability. Portability: If you write your assembler in a native language you have an assembler on that platform.

If you write it in C you have an assembler on any platform with a C compiler. This lets you, for example, compile code for your embedded platform on your workstation and move the binary rather than needing to do it all directly on the target device.

Usability: For most people, reading, reasoning about, and modifying programs is far more natural when the program is in a higher level language than when it's in assembler or worse raw machine code. Therefore, it's easier to develop and maintain the assembler in a higher level language because you can think in terms of the abstractions afforded to you by the higher level languages rather than having to think about the minutiae for which you're responsible in lower ones.

Speaking as part of the team that originally wrote the Netwide Assembler, the decision seemed so obvious to us at the time that we basically didn't consider any other options, but had we done so we would have come to the same conclusion, based on the following reasons:.

This made the decision quite easy: ANSI-compliant C aka C89 these days was the only language at the time that really hit all of those points. One thing has absolutely nothing to do with the other. Are web browsers strictly to be written using html or php or some other web content language? No, why would they? Can cars only be driven by other cars and not by humans? Converting one blob of bits some ascii to another blob of bits some machine code is just a programming task, the programming language you use for that task is whatever one you want.

You can and there have been assemblers written in many different languages. If there is no existing compiler for a new language you have to write the first one in some other language and then you eventually bootstrap if that even makes sense to bootstrap. Doesnt have to be a new language, can be an existing one. For assembly language and C the first two languages for almost all new or modified instruction sets.

We are not in the past, we are in the present. We can easily generate an assembler in C or java or python or whatever for any instruction set and assembly language we want even if it doesnt yet exist. Likewise there are many retargettable C compilers that we can output assembly language for any assembly language we want even if the assembler doesnt yet exist. That is exactly what we do with a new instruction set. Take some computer not running on our new instruction set with its C compiler that was compiled not for our new instruction set nor its assembler, create a cross assembler and cross compiler.

Develop and use that while creating and simulating the logic. Go through the normal development cycles of find a bug and fix a bug and test again, until ideally all the tools and the logic are deemed ready. And depending on the target, say it is a microcontroller incapable of running an operating system, you would never have a reason to bootstrap that such that the toolchain generates and runs using the native instruction set.

Chapter Four: Machine Emulation This chapter discusses writing an interpreter for a hypothetical machine, one that can process compiler output for the compiler the book builds. As the ADK deals with creating an assembler for a very real machine the 80x86 , this chapter is probably of little interest to those who want to write an assembler for the x86 processor family.

Chapter Five: Language Specification Ouch! Greek letters and math ahead! Lots of mathematical notation. But this chapter is a must-read!

The ADK documentation assumes you are familiar with, and know how to read, grammars. In fact, if you only read one chapter in P. Terry's book, this is the one to read; definitely a prerequisite for the rest of the documentation in the PDK. Chapter Six: Simple Assemblers This chapter provides a description of a very simple assembler.

Indeed, this is exactly the type of assembler a beginner might write were they to start off on their own without a whole lot of formal training or without using the ADK!

Of course, all of the features of a simple assembler are found in a more complex assembler, so someone wanting to learn how to write an assembler will definitely want to read though this chapter.

Chapter Seven: Advanced Assembler Features Despite the name of this chapter, it doesn't cover really advanced features you'll find in a modern assembler such as one you can create with the ADK. In fact, most of the features this chapter discusses are common even in "traditional" assemblers that aren't generally considered "advanced". Nevertheless, this chapter does discuss information like macros, conditional assembly, hash tables, and other facilities you'll want to incorporate into an assembler.

The ADK, using the information in this chapter, provides the information and code you'll need to write a really, really, advanced assembler. Yet another important chapter you'll need to read and understand in order to make full use of the ADK. Among other things, this chapter discusses grammar transformations that will be important when translating a context-free grammar into assembly code while writing your assembler.

You can safely ignore the information on LR parsers and the use of parser-generators in this chapter if you're interested only in writing an assembler the simplicity of most assembly languages do not require LR parsing techniques.

This chapter provides a basic discussion of the terms and techniques associated with syntax-directed translation. It will probably be of little interest to programmers writing an assembler with the ADK, but if you're interested in the general subject of compiler writing you may want to read this chapter.

See the comments above. This chapter also provides a brief discussion of symbol table manipulation. Chapter Fifteen: A Simple Compiler - The Back End This chapter discusses code generator for the simple hypothetical machine language the book presents earlier. It mainly discusses things like how to translate HLL-like control structures into machine code. Chapter Sixteen: Simple Block Structure This chapter discusses run-time memory management for a block structured language. The ADK supports the declaration of nested procedure declarations.

If you intend to enable this facility in your assembler, you'll want to read this chapter to learn about concepts like static links and displays at run time. Chapter Seventeen: Parameters and Functions This chapter discusses high-level procedure declarations and invocations. If you want your assembler to support high-level procedure declarations and calls e. Note that the ADK fully supports high-level procedure declarations. Chapter Eighteen: Concurrent Programming This chapter probably isn't of much interest to programmers writing an assembler.

Assembler Benchmark Generator Program. The "Assembler Benchmark Generator Program" is an application written in HLA that creates large synthetic assembly language source files in many different formats that you can use to test the performance of your new assembler.

The following entries describe features planned and currently implemented in the ADK, along with a description of the implementor and any historical notes on the code. I'll update to add some more instructions, and see if I can use it to handle the output I generate from a couple of other tools.

If so that's a win, if not then it was a fun learning experience:. Tags: asm , assembly , github , go , golang 2 comments. I think you can make your compiler even simpler by rethinking the need for Assembly.

Easier-to-transform IRs are possible. Here's mine. That said I love the idea of incrementally building up higher-levels from a simple foundation, and taking the time to consider the kind of primitives you need to build and maintain the higher levels.