Alexandre Guimar=E3es wrote: >> You say assembler and C are in different classes -- I say they aren't. >> For the tasks we do (I just assume I know enough about your projects to >> be able to say this, but I know I may be wrong), you can find some good >> engineers who would choose C and create good solutions, and you can >> find some good engineers who would choose assembler and create good >> solutions. So they are not in different classes; they are in the same >> class. > = > You are forgetting one thing that is essential ! Assembler is not really > a "language" as it's own name imply, = "Assembler" is often used as a shortcut for "assembly language" -- so what does this name imply? :) Wikipedia, for example, definitely classifies the various assembly languages as programming languages > it is not a compiler neither a interpreter. It is just a tool for easier > writing of machine language instructions. = Doesn't this go for pretty much all tools that in the end create machine language? Maybe it's time for looking a bit at the involved terms: Machine language: Usually represented in Intel hex format or binary. The language that actually runs on the target hardware. Not less of a programming language: it provides structural elements, assignment, math and logic operations, just like the other programming languages we're talking about here. It is traditionally implemented partly in hardware and partly in microcode, but it may be implemented completely in software (VHDL, for example). Just because it's usually not implemented in a tool that you can run on your PC doesn't make it less of a language. (But it may be implemented in a tool that you can run on your PC: simulators are such tools that implement machine language on a PC. Sometimes they can even be used to make the PC do things: in the cases where the simulator provides direct access to the PC hardware, like serial ports etc.) Machine language is by definition the lowest level language that's accessible on a system. Some (but not all) higher level languages generate machine language output. Assembly language: Designed to be (within limits :) readable by humans. The core of it is usually a mnemonic representation of the machine language. But there's more to it; macros and relocatable code generation/linker are probably the most prominent features that go beyond a representation of machine language. There may be multiple assembly languages for one machine language (e.g. for the 14-bit PIC machine language there's at least MPLAB assembler and Hi-Tech assembler; I think there used to be a Parallax assembler, and there may be others.). A program written for one in general can't be translated by the other, which I take as a clear indication that there's a difference between the machine language (implemented by the target hardware) and the assembly language (implemented by a tool). Some higher level languages generate assembly language output. Higher level languages: In general may be compiled or interpreted. Let's just consider the compiled ones; they usually generate either machine language output or assembly language output (for a certain assembler). I'd say for a typical program, it's probably just as much work to manually translate from C to assembly as it is to translate from assembly to machine language. I agree that there is more (maybe much more) complexity in the first task, but that's not the point. I wasn't talking about the of the tools and their complexity, I was talking about the languages. > The choices there are more hardware than software choices, Not necessarily, but even if it were so, so what? Who says that a programming language has to be implemented in software? > It is like comparing apples and oranges ! = I can't do much with this analogy; it doesn't seem to tell much -- both are fruit :) What characteristics of assembler or C are analog to what characteristics of apples and oranges? Gerhard -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist