Coding in Machine Code

[chrstrbrts]

Hi,

Is it possible to code in machine code?

There are text editors that record 0's and 1's as 0 and 1 in binary and not in their ASCII binary forms.

Could you use those text editors to write a program in machine code?

If so, how would you run it? There wouldn't be a compiler needed at all.

But, you would somehow have to get it into RAM for execution. How would you do that?

Thanks.

 

[Ken g6]

It's theoretically possible to write an executable with a hex editor. I've never met anyone who's done it.

Very, very old computers had to be programmed that way, but that hasn't been done for a very long time.

 

[WaitingForNehalem]

Take a look at assembly and assemblers.

 

[Mark R]

I've done it, but that was nearly 30 years ago, and I couldn't afford to pay the $10 for an assembler for the 6502 CPU I had, when I wanted to learn assembly.

I'd write the assembly out with pen & paper, and assemble the machine code by hand, then type it in. It was probably the least effective method of programming ever invented.

You'd be far better off getting an assembler for your selected architecture.

 

[Berliner]

There are text editors that record 0's and 1's as 0 and 1 in binary and not in their ASCII binary forms.

You mean a hex editor?

The program would be run like any other program, but it would be easier to start programming on a simpler platform than current gen Windows, which I assume you have.

And there are more efficient methods too, as mentioned earlier.

 

[KWiklund]

I've done it using a Z80 machine. The device was basically a circuit board, alphanumeric key pad and a basic 7-segment LED display. Basically you wrote out the assembly language program on paper and then looked up the corresponding op-codes using the blue book. The starting point of the program was pre-defined in memory, so your entries started there. Once you'd finished entering the program, you cjust kicked it into run mode and let it do its thing. Similarly, some labs I did as an undergraduate had us build an elementary data path out of TTL chips. Your "program" was basically the sequence of binary codes that would control various multiplexers, RAM chips etc. It's a good way to learn how a computer *really* works, but outside of an educational setting you'd almost never have a good reason to do it.

Professionally, I've had to do it only once, and that was to partially reverse engineer and then modify a portion of a former colleague's program that used an undocumented feature of a particular chip. Basically, the chip's IDE allowed you to set some filter coefficients at compile time, but you couldn't modify them on the fly. My colleague did, and I ended up having to figure out how to do it and write additional code that could do the same. The filter engines on that chip had their own peculiar instruction set, so it was a matter of discovering the op-codes and writing new programs that could be inserted into memory as needed.

 

[Merad]

Could you use those text editors to write a program in machine code?

Sure. You'll probably think "this is cool!" for the first 2-3 minutes, and after that you'll start hating it more and more.

In college we had to do this for a class. However, we were writing for a very simple simulated processor (the LC-3). I can't imagine doing it on x86.

If so, how would you run it? There wouldn't be a compiler needed at all.

But, you would somehow have to get it into RAM for execution. How would you do that?

Make a simple C wrapper program that loads the instructions into memory (a simple char buffer will suffice), makes a function pointer to that buffer, and calls it. You'll just have to tinker with linker (?) settings to ensure that the NX bit isn't set on your program's memory.

Alternatively, if you really hate yourself, I supposed you could write a full executable by hand. Look up ELF (Linux) or PE/PE32+ (Windows).

 

[chrstrbrts]

Thanks, guys.

 

[DaveSimmons]

Even on the Atari 800 and C=64 I used a real assembler not a hex editor. I did make debugging changes in hex a few times since it was faster. Especially on the C=64 where I was using the Atari to assemble then transferring the machine code with a printer cable.