Thoughts on Computer Programming

06/06/2013

Part 1 - Introduction

Solutions-For-Education.com/Programming.html

Having dealt with a number of Computer Programs, from Machine-Code and Assembly-Language constructs, and the associative Operating Systems for the respective hardware. These have been for 3rd & 4th Generation Mainframe Systems, a few Mini-Computers, through almost all of the early 8-Bit Micro-Computers, and then muddled through the advent of the 16-Bit/32-Bit/and the 64-Bit CPU architecture for PC's.

Originally, back in the days where even plotters required individual step-by-step incremental commands to "draw" letters, lines, and curves, by machine-code process. Later this was "Encoded" into the internal memory of the respective plotter. Memory devices just were not there at these early stages. Later, each manufacturer had their own "code", which may vary for different models, and now required a programmer to follow the required protocol for that plotter. Simply a lot that we nowadays take for granted. Along those same lines, there were growing at an astronomical rate a variety of Application Software Programs that encompassed like a shell around the current operating system. Even at this early stage of development, it was best to consider all of this like various onion-skins, that represented the "Layers" of all the software involved.

To a newcomer, the huge number of Application Programs is generally quite intimidating. I would suggest a few pointers to someone who wishes to delve into this apparently complex minagere, by a few simplistic considerations:

• There are actually only 2 basic layers, each of which may consist of many sub-layers.

• The very bottom layer is the Operating System (OS), which utilizes the machine-code for the actual CPU, and sub-modules for the Input-Output (I/O) Codes for "Interface" beyond itself. Basically, the individual mechanics (Machine-Code) involved, is isolated from the "User", so that the User does not have to deal with any of it.

• The layer outside of the OS Layer is actually the "What we want this system to do, or accomplish", and may be written in "Any Language we choose" (which we call "High-Level" Language). This layer simply contains the "Logic" of our method(s), and by using appropriate access points into the OS, we can pass parameters of the process we want the OS to accomplish, and even through other access points from the OS, receive feedback of various information and progress of our desires.

• On a very basic level of thinking, we can say that the OS does not care what High-Level Language is hooked in, and in the same respect the High-Level Language does not care how the OS accomplishes the machine-code processes.

• You might think that with any respective High-Level Language doing all of it's calculations that the OS is just idling along, with nothing to do. But consider that even calculations require memory access, perhaps video display, and occasional hard-disk activity, the OS has plenty to do.

Even in developing machine-code either directly part of an OS, or as an embeded program, there are only two general methods used:

1. The first is called "Linear-Programming", where the code sequences quite literally in a "Top-to-Bottom" sequence. Simple for small programs but not effecient for larger more complex programs.

2. This second method is generally called "Modular-Programming", because the programmer constructs re-usable modules, called "Sub-Routines", called by either the Main Program or even other Sub-Modules. The advantages are numerous:

   • These modules can be established for the function(s) required
   • They result in quick developement of larger, more complex routines or programs
   • In the long run, they actually become addressable by "High-Level" programs by "one statement commands".

Having said all of the above comments, I would like to point out that any and all High-Level Programs are actually composed of Machine-Code Modules, that have a number of Machine-Code Commands to execute a number of appropriate steps to perform the necessary actions.

Now, consider that whether we are using FORTRAN, PASCAL, BASIC, any and all versions of "C", FORTH, PROLOG, any and all versions of CAD, the "VISUAL" versions of any number of programs, any and all versions of DATA-BASE programs, and even various WORD PROCESSING and SPREADSHEET programs, they all have at their very base a series of custom Machine-Code Modules.

The challenge for anyone attempting to learn any particular High-Level Language, is faced with learning the "Syntax", and perhaps a number of formidable assocaitive requirements.

Once you have gained some familiaity with one high-level programming program, you most likely will see a number of comparisons with some other programming programs.

When you install a "Driver" for any device, this is again a set of custom Machine-Code Modules for the respective device.

One example of this (long ago) was in the department of "Structures Test " that I was in, at the Boeing Space Center in Auburn,Washington. We worked a lot with vibration analysis testing of various payloads. Some of the engineers came up with a method of evaluating and correcting various errors in the respective control data as it was acted upon by the "Shaker-Pots". Like in even common speakers, where they are not 100% in their faithful sound output as required, there was a slight problem in true replication of the frequencies and their energies, applied to the various payloads mounted on the vibration tables. They concocted a specific signal pulse to be transmitted down to the Shaker Tables, then analized the resultant feedback signal against the original to determine the degree of "coloring" that happened. To simplify the matter, they determined what they needed to compensate all outgoing signals, to get what they really wanted. The Engineers used Fortran as their high-level program, and I constructed a Machine-Code program to access the hard-drive and high-speed buffered interrups for the actual data I/O. I provided the "hooks" for their Fortran programs so that they could do all their calculations. In escence, my machine-code program was attached to the current OS as actually embedded into the OS, rather than as an outside shell. In escence, my machine-code program was the "Driver", required by the engineers for their FORTRAN Application Programs.

Go to Programming - Part-2 (Basic CPU Comparisons)

Return to Programming (Menu)