1. what is the difference between multiprogramming and multiprocessing? Multipro

Question

1. what is the difference between multiprogramming and multiprocessing? Multiprogramming and multithreading?

2. Why should assembly language be avoided for general application development?

3.Under what circumstances is assembly language preferred or required?

4.Under what circumstances would you argue in favor of using assembly language code for developing an application program?

5. What are the advantages of using a compiled language over an interpreted one? Under what circumstances would you choose to use an interpreted language?

Explanation / Answer

1)

Multiprogramming
In a multiprogramming system there are one or more programs loaded in main memory which are ready to execute. Only one program at a time is able to get the CPU for executing its instructions (i.e., there is at most one process running on the system) while all the others are waiting their turn.
The main idea of multiprogramming is to maximize the use of CPU time. Indeed, suppose the currently running process is performing an I/O task (which, by definition, does not need the CPU to be accomplished). Then, the OS may interrupt that process and give the control to one of the other in-main-memory programs that are ready to execute (i.e. process context switching). In this way, no CPU time is wasted by the system waiting for the I/O task to be completed, and a running process keeps executing until either it voluntarily releases the CPU or when it blocks for an I/O operation. Therefore, the ultimate goal of multiprogramming is to keep the CPU busy as long as there are processes ready to execute.
Multiprocessing
Multiprocessing sometimes refers to executing multiple processes (programs) at the same time. This might be misleading because we have already introduced the term “multiprogramming” to describe that before.
In fact, multiprocessing refers to the hardware (i.e., the CPU units) rather than the software (i.e., running processes). If the underlying hardware provides more than one processor then that is multiprocessing. Several variations on the basic scheme exist, e.g., multiple cores on one die or multiple dies in one package or multiple packages in one system.
Anyway, a system can be both multi programmed by having multiple programs running at the same time and multiprocessing by having more than one physical processor.

Multithreading
Up to now, we have talked about multiprogramming as a way to allow multiple programs being resident in main memory and (apparently) running at the same time. Then, multitasking refers to multiple tasks running (apparently) simultaneously by sharing the CPU time. Finally, multiprocessing describes systems having multiple CPUs. Multithreading is an execution model that allows a single process to have multiple code segments (i.e., threads) run concurrently within the “context” of that process. You can think of threads as child processes that share the parent process resources but execute independently. Multiple threads of a single process can share the CPU in a single CPU system or (purely) run in parallel in a multiprocessing system

2)

So, assembly language be avoided for general application development.

3)

The following circumstances are assembly language preferred:

4)

The assembly doesn’t contain the inbuilt functions, tools and procedures. The programming on the assembly language is a very hard task. The maintenance and update of that programming language is also very hard. It requires every task to be done form the scratch that made it hard to use that language and it is the main reason to avoid the assembly language on application development. The assembly language is a low level programming language. It provides the users exclusive control over the code. The code can be used while the program don’t need much updates in future. The assembly is directly relates with machine instruction. The hex code and binary code are much suited in that and it execute every fast.

5)

Compiled native code does not have the overhead of an interpreter and is therefore usually more efficient on time and space

Interoperability is usually better, the only way for in-proc interoperation with scripts is via an interpreter rather than a standard FFIAbility to support architectures the interpreter hasn't been compiled for (such as embedded systems)

Related Questions

Navigate

• Browse (All)
• Browse 1
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.