[Exspiminator-commits] CVS: exspiminator/docs asm-tutorial.html,1.8,1.9

[Nigel P. <nph...@us...>]

Update of /cvsroot/exspiminator/exspiminator/docs
In directory usw-pr-cvs1:/tmp/cvs-serv17947/docs

Modified Files:
	asm-tutorial.html 
Log Message:
Fix spelling.

Index: asm-tutorial.html
===================================================================
RCS file: /cvsroot/exspiminator/exspiminator/docs/asm-tutorial.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -r1.8 -r1.9
*** asm-tutorial.html	2001/11/19 16:17:49	1.8
--- asm-tutorial.html	2001/11/21 11:41:30	1.9
***************
*** 16,20 ****
  </ul>
  
! <p>The GPRs are identified by the names <code>r0</code> to <code>r31</code> and thus there are 32 of them. These registers all function the same way (except <code>r0</code>, which has some special usage which is described in the section "<A HREF="#A0">Special case handling of <code>r0</code></A>") and are used for all integer operations: PowerPC is a "load/store" architecture in that operations on values in memory cannot be done <em>in situ</em>. To add, multiply, xor, or compare integers, etc, we must first load the integers into the GPRs. (Similarly, floating point arithmetic can only be done on the floating point registers.) So to perform an operation on a value in memory, we must load the value, perform the operation, and then store the value back into memory. This separation of instructions involving memory access and those operating on data is just one example of the "loose coupling" of the funtional untis implied by the PowerPC instruction set.
  
  <p>The functional units in a PowerPC chip are loosely coupled, by which I mean that most instructions affect only one processor unit (there are at least three "units" conceptually: an integer processing unit, a floating point processor unit, and a branch processor unit). Integer operations only involve the GPRs, floating point operations only involve the FPRs, branch operations usually only involve the branch registers (etc). This separation is an efficiency measure: by minimizing the interfaces between functional units, the interdependencies between instructions becomes easier to detect, which increases the opportunites for - and decreases the cost of - executing multiple instructions in parallel (i.e. at the same time). The drawback is that it sometimes makes life more difficult for the programmer... for example there is no interface between the floating point unit and the integer unit except main memory: to transfer a value from a GPR to an FPR you first have to store to RAM and then load it into an FPR.
--- 16,20 ----
  </ul>
  
! <p>The GPRs are identified by the names <code>r0</code> to <code>r31</code> and thus there are 32 of them. These registers all function the same way (except <code>r0</code>, which has some special usage which is described in the section "<A HREF="#A0">Special case handling of <code>r0</code></A>") and are used for all integer operations: PowerPC is a "load/store" architecture in that operations on values in memory cannot be done <em>in situ</em>. To add, multiply, xor, or compare integers, etc, we must first load the integers into the GPRs. (Similarly, floating point arithmetic can only be done on the floating point registers.) So to perform an operation on a value in memory, we must load the value, perform the operation, and then store the value back into memory. This separation of instructions involving memory access and those operating on data is just one example of the "loose coupling" of the funtional units implied by the PowerPC instruction set.
  
  <p>The functional units in a PowerPC chip are loosely coupled, by which I mean that most instructions affect only one processor unit (there are at least three "units" conceptually: an integer processing unit, a floating point processor unit, and a branch processor unit). Integer operations only involve the GPRs, floating point operations only involve the FPRs, branch operations usually only involve the branch registers (etc). This separation is an efficiency measure: by minimizing the interfaces between functional units, the interdependencies between instructions becomes easier to detect, which increases the opportunites for - and decreases the cost of - executing multiple instructions in parallel (i.e. at the same time). The drawback is that it sometimes makes life more difficult for the programmer... for example there is no interface between the floating point unit and the integer unit except main memory: to transfer a value from a GPR to an FPR you first have to store to RAM and then load it into an FPR.