Learning Assembly language

rcgldr

That would be CPM-86. Wiki article:

http://en.wikipedia.org/wiki/CPM-86

CPM ran on the older 8080 compatable instruction set. You could also run CPM with an 8085 or Z80.

pairofstrings

Thanks for writing. You can call me "a bit masochistic" or ...whatever. I set challenges on myself because I like it. And if you have read my first post of this thread, I have already mentioned that I have immense amount of time and I want to learn pure assembly language. I think learning pure assembly language is going to help me a lot in understanding complicated functions of a computer and I can design some impressive system as my project when I take higher studies in electrical engineering. I have also mentioned my method of learning in post#13. Hope that answers your curiosity. Please read all of my posts. I write nice stories, you will not get bored.
Please tell me if I have correctly understood the meaning of embedded ASM and C language programming.

EDIT: Sorry, I wrote "embedded ASM and C language programming" above. I was actually referring to the part where I can use assembly language code in my C language program in the C language editor, like in Turbo C/C++ version 3.0 editor and compiler.
Anyways, thanks for the information in post#20. But my two questions in figure 1 of post#13 is still not resolved. It is about (Turbo) C/C++ compiler and C program containing ASM code. And there is another question in same figure 1 of post#13 as well. Please see figure 1. Please comment on my first figure of post#13.

I have found some interesting things on the internet regarding a Processor and RAM limits. But could not understand the text. I shall come back to this topic for discussion once I get answers to all my questions in the figures of post#13.

I have fixed all my pictures in post#13. So, please write. All the comments and corrections and discussions and analysis are welcome. Please see my post#13 and tell me what is wrong and how it could be correct and please answer my questions from all the figures. Thanks.

rcgldr

Embedded applications are ones that go into devices other than than a typical computer. This could include a hard drive, a cell phone, a microwave oven, an ECU for a car, ... . The basic coding methods are the same, but the interfaces that the code works with are different than a PC and how the code is initially loaded on the device is different. The operating system, if any, will be different than the ones normally used on a PC.

Wiki article for embedded system.

http://en.wikipedia.org/wiki/Embedded_system

PaulS1950

pairofstrings,
To embed another language in a C program you write the assembler code (or pascal, fortran, whatever) and compile to obj file. Then you link the obj file to your C file with the linker and build the program from there.
It is a way to expand the capabilities of C to include routines in other langauges. Those who use assembler (machine code) in their C programs do so for the added speed or to address a machine specific attribute on an otherwise portable code. The problem for me is that embedded code is rarely portable outside of the specific processor family. That doesn't work for me and it is why I only use ANSI C (C-89) currently. I give up some of the easy processes but I gain speed and portability.

Paul

phinds

I would hardly call that embedded code. That's just linking to a separate library and nothing to do with embedded code.

EMBEDDED code, in C is literally that. You put ("embed") assembly language statements IN the C program (with the appropriate surrounding statements so that the C compiler knows to assemble it instead of try to treat it like C.

pairofstrings

Above mentioned trick is interesting. It shows how compiler developers have managed to make things easier but I think they did it by doing some compromise with the performance.
Anyways. So, if I want to embed some chunks of assembly language code in C code. Then, I could just pick up my Turbo C/C++ compiler, version 3.0 and type my assembly language code inside this Turbo C/C++ editor along with the C code. And then compile(?) the code (containing mix Assembly language code and C language code) by pressing ALT F9 and run the compiled(?) program by pressing CTRL F9. Right?

Speaking of assemblers...

After my post#13 I figured out that there are assemblers specifically designed to support a group of specific processors/microprocessors. For instance, Intel processors have their own assemblers, though there are of different types like FASM, MASM, NASM,TASM.
Let us assume range from 80x86 to the (present) i7 processor from Intel, whether 16-bits, 32-bits, 64-bits. I am yet to find out why there is no sole assembler that could work on all these types of microprocessors. I mean, I want an assembler that could target all microcontrollers and all microprocessors which are following Intel's internal architecture design of microprocessor whether 16-bit , 32-bit, 64-bit. I mean, I can have three different assemblers that targets 16-bits microprocessor or 32-bit microprocessor or 64-bit microprocessor individually. Or maybe, I would just have a single assembler that could target all the microprocessor whether 16-bit, 32-bit or 64-bit, provided that these microprocessors are manufactured by Intel because then these microprocessors would have same Internal architecture except the input/output pins changes. And only the size of the registers changes but the quantity of registers are same. True?

ARM processors have their own assembler. Perhaps, the instruction set of these two different types of microprocessors manufactured by Intel and ARM could vary. So, I think the point is if the microprocessor designer includes an extra register (and other component inside microprocessor?) then an existing assembler becomes obsolete for this newly custom designed microprocessor. And I think this was discussed earlier that the instruction set varies from one Operating system to another. For instance, the instruction set of Windows Operating system is different than Unix Operating system. The point here is instruction set varies from one Operating system to another depending on the code design of the Operating system. True?


Another point here is, if the microprocessors are SAME in both Windows Operating system and Unix Operating system but code design is DIFFERENT. Then going by my discussion in this post, I will not require a new assembler but the instruction set varies. True?

The overall point here is
1. If I have SAME microprocessor used in Windows Operating system and Unix Operating system then there is no need to design and develop a new assembler. But the instruction set may vary depending on the code design of the each Operating system. True?

2. If microprocessor used in Windows Operating system is DIFFERENT than what is used in Unix Operating system then there is a certain need to design and develop a new assembler. Again, here the instruction set may vary depending on the code design of the Operating system. True?

I am still under dilemma to choose a good, powerful assembler that could help me target all types of microprocessor, manufactured by all manufacturers like Intel, ARM, AMD etcetra.

Let me know if all of my above reasonings are correct or am I just wandering.

I cannot deduce answer to the following text :
Suppose, I have a Unix Operating system running on 32-bit Intel's microprocessor. So, I don't need to develop an assembler. I can use the existing ones. It is not necessary that there must always be an assembler installed in a PC to make an Operating system run. So, since I am running Unix, we all know that instruction set of Unix is different from Windows.
My confusion is : Is it because of code design of Operating system or is that the instruction set to implement a logic in a PC can change irrespective of code design of Operating system and design of microprocessor. Is there a possiblity like this?

Let me put it in simple terms. Suppose, I have a "64-bit Operating system1" running on Intel's 64-bit microprocessor. And I have the same "64-bit Operating system1" running on the same Intel's 64-bit microprocessor. My confusion is: Is there a possibility that even though Operating systems are same, the microprocessors used are same, can the instruction set used to implement the logic to achieve the same objective in both the machines be different?

Please tell me if the above written reasoning s are true. So, that I can learn something. Thanks.

I need to clear my confusion between Operating system size and computer word size. I need to find the purpose of each register in any given microprocessor. I need to find how the loop mechanism in assembly language works. I need to find more about INT instruction in assembly language. So, I will write my explanations here. So that you guys can evaluate my answers. And I will paste some text that I got from the web, which is related to question#2 in my post#13. So, that you all can explain me the meaning of that paragraph. I will write a separate post on all of this in this thread later.

My next post will be on making a home made computer from scratch. Not really from scratch. I will describe it in detail in my next post. So, that you guys can help me a bit.

phinds

No that is not correct. there is no compromise with performance. Embedded code is generally done to IMPROVE performance.

I haven't used that compiler in so long that I don't remember the specifics, but generically, yes, that's correct.

Well, duh! Assembly language === machine language in another form. That is, assembly language follows machine language according to the principle of one-to-one correspondance. Assembly language is an EXACT representation of machine languge. Different machine have different machine languages, so OF COURSE they have different assembly languages by definition.

Microprocessor series (such as the x86 series) generally add registers / capabilities in the newer versions, so while assemblers COULD be made completely backwards compatible, that's a design (of the assembler) issue.

ya think ?

You really need to drop this belief that assembly languages / machine languages and operating system have anything to do with each other. They are different level constructs entirely. You can write any operating system on any machine, if you so choose.


WAY off --- the "code set" of an assembler is EXACTLY the code set of the machine and has NOTHING to do with any operating system than may be written for that machine.

Yeah, since such a beast doesn't exist, I'm sure you're having a hard time choosing one.

AGAIN --- drop this idea that machine language and operating system have anything to do with each other.

They have NOTHING to do with each other except to the extent that if you have a 64-bit machine and the operating system takes full advantage of it, it is called a 64-bit operating system, but if the operating system was written for a 32-bit version of the machine and yet is running on a 64-bit version of the machine, it is NOT taking full advantage of the 64-bit machine and it is called a 32-bit operating system.

rcgldr

It's not clear which meaning of "embedded code" that you want. "Embedded code" could mean software that runs on some device, such as a hard drive, cell phone, ... or it could mean embedding assembly code into C code.

Performance may be comprimised. In some cases, optimization, especially register based optimization, is reduced or disabled if embedded assembly code is used, since it would be difficult for the compiler to know which registers or which locations in memory are modified or preserved by the assembly code.

You'll probably need two assemblers. MASM (actually ML.EXE) 8.0 from Visual Studio supports 32 bit and 64 bit code. Masm 6.11 supports 16 bit and 32 bit code. The syntax for Masm 6.11 and later is the same. Masm 5.xx versions are lacking some of the features of Masm 6.11. MASM 8.0 supports 16 bit mode, but I doubt Visual Studio's linker or libraries support 16 bit real mode code, so you'll need a different tool set, even though MASM could be the same.

AlephZero

In practice, the compiler documentation will tell you want conentions your assembler code has to follow. For example the compiler wll have some program-wide coventions about how it calls and returns from subroutines and allocates local temporary data items on the stack, and if your assembler code doesn't respect those, most likely nothing will work.

But that isn't really a "restriction". It just means you can't invent your own arbitrarily different way to do something that you would need to do anyway, for a non-trivial-sized progam - and the compiler writers are not likely to have invented a deliberately inefficient and dumb way to do it, just out of cussedness!

I think much of this discussion about what is different from what is getting somewhat fanciful, because the days when programs like compilers and assemblers were hand-coded by "expert programmers" have long gone. Any decent computer science course should teach you how to build your OWN working compiler for a high level language, as a term project. It probably won't be super-efficient, or generate super-efficient code, but at least it will work - which is better than many "hand-crafted" products from the past!

Most of the code making up compilers for completely diferent languages (as different as traditional Fortran, is from C++) is absolutely identical - which is why you no longer have "compilers" but "compiler systems" like
http://gcc.gnu.org/ , which support a whole range of languages across a whole range of CPU types (including Intel, ARM, and several more besides) and different operating systems.

Most modern compilers don't generate machine code directly, but output an assembler language program, which then gets processed by (big surprise!) an assembler - and you can run the assembler yourself on your own assembler code if you want to.

rcgldr

The main issue is the usage of registers for variables by the compiler to optimize code. In the case of microsoft c compilers, embedding asm source generally requires the compiler to store any register based variables into memory before the embedded assembly segment and then to restore them back into registers if optimization warrants it.

One way to avoid this issue is to keep the assembly code and C code in separate source modules (separate object files that get linked together), and have the C code call the assembly code or vice versa.

pairofstrings

God, my English is horrible and so is my ability to portray my thoughts in written format. I know, I must work on that.
Sorry that this discussion is beginning to look fancy. But, I want to know, and I think that this is useful information for me.
Anyways.

Okay. Thanks for making it clear for me. I now know about 'compiler systems'. Thanks for bringing it up.

1. But you mentioned that compilers made by not-so-expert programmers these days are able to run a piece of high level language code nicely. And these compilers created by not-so-expert programmers are better at giving the performace when compared with the performance of the code that were "hand-crafted" products from the past. Are you saying that these "hand-crafted" programs written by expert programmers were written in pure Assembly Language? And still the most of these "hand-crafted" programs written by expert programmers using Assembly Language are not as efficient (performance wise) when compared with the programs written in high level language and then use compilers created by not-so-expert programmers to compile and machine code generated is good enough that it is better than "hand-crafted" Assembly Language programs written by expert programmer.

If that is what you are saying, then I believe that it is perfectly possible that an expert-programmer can write a code whether intentionally or unintentionally to run with low performance. Simply, because I think it is possible to write bad code even in Assembly Language which is the same case with writing code in any high level language. Your thoughts, please.

2. What is "assembler code" in your last paragraph (please, see above)? Are you referring to assembler(translator) design code? Or is it "assembly language code" and you typed it as "assembler code" ?
I get a feeling that, what you basically meant is that when a compiler system tries to generate a binary code (machine code), this compiler system translates the high level language code to "assembly language code" ( the code which contains mnemonics like ADD, MOV, SUB, MUL, etcetra). And I can simply extract this "assembly language code" and run it on my beautiful assembler. And by "extract", if I can do that, that will also mean that I can "hand-craft" this extracted-compiler system generated-assembly language code to make it more good. Right? Possible?

This comes as a big of surprise for me that there is an assembly language program running inside the HDD! I did not know that. I was always thinking that Operating system was in-charge of extracting/writing the data from/to the memories of a computer (like HDD, RAM). And I also thought that when I attach a pen drive to my USB port, even then the Operating system is in-charge of extracting/writing data from/to the pen drive. Am I right about this thing or is there an assembly language code sitting inside this pen drive as well. The reason why I thought that there is no assembly language code running inside HDD and pen drive is that, I assumed that, if suppose, I buy a new HDD and pen drive and attach it to my computer which has no Operating system installed. And if the monitor is also connected and there are device drivers for my display then when I connect my HDD and switch my computer ON with no Operating system installed in it then, I thought the HDD will be only consuming power and nothing else. But, if I can write an assembly language program inside an HDD then that means if I connect this HDD to my computer which has no Operating system installed in it then the assembly language program running inside HDD can be programmed to inform the user by saying "there is no Operating system installed and you must install the Operating system to enjoy full benefits of HDD technology." I mean that is great. Now, I think that assembly language code cannot be written inside RAM. If assembly language code can be written inside RAM, then I can program my RAM to inform the user by saying "not enough RAM, please insert more RAM" whenever computer is running out of RAM. That will be cool. Right? If I may add, the same programming ability can be applied to Graphics card. If a user is trying to play games that require powerful Graphics card. And if I can write assembly language code inside Graphics card then I can program my Graphics card to inform the user by saying "Not enough power inside Graphics card, please upgrade." Your thoughts, please.

And I was actually pointing to the concept were I can write my Assembly Language code inside C Language code in the same editor window. But, thanks for information in post#20 and post#27 on "Embedded system programming". I might be starting Embedded system programing using only Assembly Language and using only C Language and using 'mixed Assembly and C code'. People say 'mixed Assembly and C coding' is difficult. But, I am just trying to do something useful and learn something.
Your thoughts, please.

Thanks for making it clear. I now know that instruction sets written in assembly language are not linked with Operating systems in any way and and I can write my Operating system on any machine. This was also my doubt. But the real thing that I wanted to know was...

Objective:

Suppose, if I am running Unix Operating System on one machine. And Windows Operating system on another machine. Let us assume that the microprocessors used are same in both the machine. Because, by making assumptions like this, I do not have to consider using two separate assemblers on these different Operating system, and it gets simple to write my query here. So, so far hardware and assembler is same on both the machine. But, only the Operating system is different from one another. Now, my objective is to write a software for these two machines. Let us write a software called EditPad. Similar to MS Notepad. Let us remind ourselves again that we are using same hardware and assembler on both the machine but the Operating system is different.
Now, I want to create minimize button, maximize button, close button, title bar, menu bar and outer frame for my software called EditPad.
So, since we are having different Operating systems, I think that code required to build all those components of that software (EditPad) must be programmed separately if I want to include this software (EditPad) in each Operating system software package.

Please look at it this way...

On Unix if I want to create a close button then I may write following steps :
.
.
.
MOV [somenumber], [somenumber]
ADD [somenumber], [somenumber]
MUL [somenumber], [somenumber]
.
.

and other instructions which will help me create the button.

On Windows if I want create the same close button then I may have to include extra steps/instructions which is not similar to instruction/steps used in creating the same close button in Unix Operating system.

.
.
.
MOV [somenumber], [somenumber] -----> possibly, there could be different numbers than used in Unix Operating system to create the same close button
ADD [somenumber], [somenumber]
MUL [somenumber], [somenumber]
SUB [somenumber], [somenumber]
myloop: ------> extra instruction used here, not used in Unix Operating system to create the same close button
.
.
.
end loop
.
.
.
and other instructions which will help me create the button.

I am not trying to reverse engineer any software or Operating system. I am just trying to realize the possibilities how instruction set a.k.a instruction can vary between two Operating System when trying to achieve the same objective. In this case the objective is to create a software called EditPad which will look exactly similar in appearance and will have exact operations to perform for both Unix Operating system and Windows Operating system.

Unix:
Instruction set to achieve an similar objective: (In this case same button creation in software called "EditPad")
.
.
A
B
C
D
E
. (Instruction F is missing here but F is present in Windows)
.

Windows:
Instruction set to achieve the similar objective: (In this case same button creation in software called "EditPad")

.
A
C
D
F (instruction E is missing here but E is present in Unix)
.
.
.

True?
So, so far I know that instruction sets varies from one OS to other (different) OS but this variation is independent of what assembler I use. And the industry still do not have the ideal assembler that I spoke about earlier.
But can you put some light on my objective in this regard.

Your thoughts, please.

chiro

Hey pairofstrings.

The main differences between the two mostly deals with OS specific routines (as your probably realize) and these usually are implemented in a variety ways depending on the design and execution constructs of the operating system.

If you want to learn the specifics, you need to learn about the execution constructs like process and threads and all about them. You need to know how memory and other resources are allocated to processes and threads.

You also need to know how DLL's (or SO's in linux) are organized. Knowing this won't only help you understand custom applications that use custom DLL's, it will also help you understand how operating system routines are called from executables which will help you see automatically the difference between 'windows code' and 'linux code'. This is what happens when you want to call windows code like opening a file or creating a thread: you are calling a routine in an external library (DLL) and that will do what it has to do and modify objects in memory that it has to modify for the calling program.

Typically we don't do things like we used to which has based on software and hardware interrupts. This was back when developers just directly interacted with the hardware: for various reasons we don't do that (this is a good thing) so if we want to do OS specific things instead we call routines in an OS library which do things for us and also protect different processes from accessing other processes objects like memory, file handles and other things.

The other thing has to do with all the structures in an executable. Knowing these will help you understand all the code that gets called to initialize the program. EXE files are usually in the portable executable format, and this has a whole bunch of information that will help you understand what gets setup specifically to the OS before your 'non-OS' specific code gets called. Linux has its own structures for executables in the same way that Windows has.

rcgldr

The problem here is that Unix / Linux systems typically use an X Windows graphical user interface while Windows uses it's own graphical user interface. These are not compatable. If you wanted to share code on both systems, you would need to select some common graphical user interface, which wouldn't be native to Linux or Windows or both, such as using an X Windows interface on Windows 7.

nsaspook

Yes, something like QT. http://en.wikipedia.org/wiki/Qt_%28framework%29

http://qt.nokia.com/qt-in-use/story/app/vlc-player/

pairofstrings

Am I saying anything? Yes.

Please see the figure below.



Question 1:
In the above figure, I chose figure 1 as my answer. And I do not know if I can develop graphics and GUI using pure assembly language. But, I think that it is possible to even draw figures, graphics and develop graphical user interfaces/windows and applications/softwares using pure assembly language. Correct me if my understand is wrong.

I know that, C language was used to build JVM and JVM makes codes run independent of all architectures. And if C language is third generation language which came after assembly language which is second generation language. Then I get an impression that C language was designed by taking the ideas of Assembly language, then how come we cannot write web applications in pure assembly language if we intend to write the same web application in terms of implementing it by implementing JVM code indirectly and Web application code in the same assembler's editor. And then assemble it. Create an assembler file compatible with web standards and put it on the web.



Question 2:
I mean, If I want to write web application code in such a way that it is able to run on all platforms then I can write it by even implementing the 'JVM' code and the web-code in the same assembly language's editor window. Is not that a possibility? I am not trying to reinvent the wheel. I am sure that the elite peers and the researchers have already worked and studied it. But I am just curious to know if there is any tiny possibility of doing this using pure assembly language. Please see the figure above.

I get an impression that the mere purpose of doing all of this (going to higher level of abstraction) is to get/impose security in a wayward manner which is not elegant at all.

Thanks and appreciation.

phinds

The statement and others you have made tells me that you have a fundamental misunderstanding.

ANYTHING that can be done on a computer can be done in assembly language.

You would be utterly insane to actually DO it, but it CAN be done. To recreate the OS utilities, including graphics routines, that make many thing easy to do COULD be redone by you in assembly language, but probably not in one lifetime.

After all, whatever code you start out with, it RUNS as machine code and assembly language is just a literal translation of machine code into human-readable form.

phinds

Regarding your question #2, I'm not sure that I understand exactly what you are proposing. You keep talking about "pure assembly language" and then talk about running it on different platforms.

Do you not understand that each CPU has ITS OWN assembly language? You cannot run one machine's assembly language on another machine and if you write code to try to convert one machine's assembly language to another machine's assembly language, that will be somewhere between near-impossible and possible but just plain dumb.

Implementing something like the JVM on each machine would be much more reasonable, but when you do that you HAVE to get rid of this concept you have of "pure assembly language" running on different platforms.