quote:
Actually assembly *is* a (the) second-level language. Machine (binary) code is the first level, assembly is the second level, and high-level languages are the third level.

Actually...machine language (or binary)...is *THE* base language [0]...assembly is the first-generation language [1] developed inorder to make programing easyer...second-generation languages are COBOL and FORTRAN again developed to make programing easyer...third-generation languages are PASCAL, C, and BASIC (developed to make programing easyer, but also to re-inforce 'structured' programing techniuqes)...fourth-generation languages were/are developed to address Object Oriented (OO) programing like JAVA, C++ (remember Turbo C? LOL!)...then their are fifth-generation languages like LISP, FOXPRO, etc..

If a program is compiled (through compiler or assembler...linked, etc.) it is translated into machine code (obviously) and is at that point a first-level language...if it needs to be interpreted at run time (JAVA, good old Quake-C, VB, etc...) then it is a second-level language.

Assembly is usefull to learn because every language still has to use the processer for anything to be acomplished...there are no special opcodes on the processor that OO programing uses...ANYTHING that can be done in any other language, can be done in assembler. and if you can learn assembler, then most other languages are a piece of cake

quote:
Hex is no machine format and entering "mov eax,24" is quite different from feeding the processor something like "0101011100011101110111".

"mov eax,24" is not Hexadecimal notation (or simply Hex)...

In the dawn of computer programing, thier were 'punchcards'...a machine would read the holes on the cards as "1"s and non-hole areasa as "0"s...course this was before computers universaly used moniters (instead they used printers)...when moniters (terminals on main-frame systems) became common place...programming could be done by entering 1's and 0's...but by the time moniters were able to show whole letters and generaly mimic the output the printers could do...codeing in 1's and 0's became obsolite as Hex editers could be used instead...

Hexadecimal notation is nothing more then converting 4 bits into a 16-base numerical system (0 through F...a byte is then represented by two Hex characters 00-FF, course I suspect anyone who is somewhat interested in assembler already knows this)...you very much CAN program in "machine language" (or "binary") by useing a Hex editor (which is how most people do it)...

Assembly doesn't exactly translate into machine language...

ADD AX, BX
ADD AX, 6

will translate differently because it makes a difference in that one statement adds one register to another...while the other statement adds a set value to a register...which, of course, makes a big difference to the processor





[edited by - MSW on October 17, 2002 10:00:18 PM]

For all practical purposes, assembly language _is_ machine language.

Assembly language is simply a textual representation of machine instructions. There is a 1:1 mapping.

You can sit down with a processor reference and start coding in assembly for just about any given processor.

Moving down to the actual 1s and 0s does absolutely nothing for you. It doesn''t even really give you more control over things. Assembly language is nothing more than a convenient way to work with processor instructions. You can reorder them and directly understand how the processor will execute your code.

Things like labels aren''t as abstract as you think and assemblers themselves differ greatly from compilers for "true" high level languages. Labels are nothing more than unresolved addresses. It''s much more convenient to work with labels and identifiers that can be calculated all at once rather than having to change them each time you insert a new instruction. The assembler and linker take care of this tedious work for you.

You can argue that it''s a higher level language than actual machine code, but don''t make it sound like it''s an entirely different language -- it''s the same thing, just easier to represent (and with extra assembler-provided features like macros, etc.)


---
Bart

quote:Original post by Anonymous Poster
The only case when you would actually need to code instructions in machine language, instead of assembly, would be when there is a bug in your assembler or there''s some new instruction(s) that aren''t supported in the assembler you''re using.

Right. If you''re writing your own assembler or something that has to generate code on the fly, you''ll have to deal with machine language. Any assembly language programmer can simply pick up a processor reference manual and figure out how to write the machine code.

quote:
If I would have the time, I would code a game entirely in asm... well, actually I''m writing an OS from the scratch with NASM

Cool! Writing system-level code is a great way to learn about how things really work (if you haven''t already done so.) I remember doing similar projects.

There''s 1 piece of advice that I''d like to give regarding OS projects: Try to use C.

By this I mean figure out how to set up a compiler (gcc) to allow you to compile your OS and cross-compile programs for it. I haven''t tried doing a real OS, but I''d imagine that attempting to do it mostly in C would force me to think out more of the basic design ahead of time. I''d have to figure out exactly what needs to be written in assembly and what can be left to C, and then how to set up my compiler to produce system code the way I want it to be layed out.

Just a thought. The most important things are to learn and have fun, of course

---
Bart