[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] hex

Dear troll:

Far be it from me to impede your learning process!

There is a semantic, rather than a substantive difference you should note:
common usage of 'machine language' is for a binary image of codes and
numeric data as they are loaded into the array of your computer's memory
for execution. 'Assembly language' commonly refers to a sequence of
machine instructions and numeric data in the form of mnemonic tokens and
numbers (expressed in various radii). The tool which translates from
assembly language to machine language (well, close) is called an
'assembler' #8^)K. You can also take advantage of tools like 'linkers' and
'loaders' to help you manipulate the assembled "object code." There is no
penalty, and great convenience, in using these tools compared with
manually setting contents of memory registers. Once you have done enough
of that 'poking' and 'peeking' to understand how the various
representations coincide, you can take advantage of these tools and still
maintain a 1:1 correspondence between what you write and what you expect
to be executed at the instruction and register level.

I was startled to find about two years ago, that versions of M$
Developers' Studio at my previous employer did _not_ provide an assembler,
nor were there more than veiled references to such arcana in the
developers' database. Instead one was encouraged to embed
assembly-language sequences in the higher-level [C] code. What a
maintenance and portability nightmare!

It seems to be getting harder to learn this stuff than when some of us
'long in the tooth' specimens got started. (I also walked five miles
through the snow to school every day and it was uphill both ways!)

To learn very efficiently at this level, you will need some way to move
your image into a computer's memory and start executing it. You can start
in a fully-functional computer (i.e., a PC running your favorite OS) and
use a debugger for this: although there is a _huge_ amount of
infrastructure working for you, you can ignore it and concentrate on the
effect produced by your code, which is almost always edifying. Especially
compared with what you hoped it would do!

A good follow-on step might be targeting your code for a 'generic' PC
motherboard with no OS and few peripherals. You would need to install or
load a debugging "stub" on the board, then work a debugger (such as 'gdb')
over a serial or other interface from your development-host PC. Check the
'embedded' and 'real-time' projects like 'eCos' [RedHat] and 'RTEMS'
[OARCORP] for some materials.

Have fun.

Regards -
 John Mills

P.S. Around 1986, I actually met a programmer who worked only in machine
(pure binary) language. He said this was the only way he could visualize
the timing of such features as 'bit-banger' serial interfaces and
sensor-test loops in his firm's security products. The embedded code was
about 1-2K in size, I think. I _strongly_ recommended to his employer that
they obtain a 'disassembler' (these exist) and create a readable copy of
his code, both for design documentation, and to support possible porting.
They declined to do this. Unfortunately their product was based on the
Fairchild micorprocessor family, which was discontinued a few months after
I made my suggestion. I don't know the impact this had on the firm, nor
will I identify it.

On Fri, 11 May 2001, Stephen Turner wrote:

> well then, how do people program in machine language?
> i want to make REALLY tiny programs and if i use c c++
> or similar there will allways be unneeded code there
> from where it has to be compatible with many different
> instances... my understanding is when its compiled it
> has stuff it may never use cause it was not needed to
> run the program. i want to write stuff for bios, boot
> records, and programs that are tiny so they execute
> faster not to mention its good practice :) your
> telling me i cant edit notepad? why do programs cease
> to work if you change the overall size of them in a
> hex editor? im here to learn! feed my hunger! hehhee 


To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.