My Thoughts on Computer Programming:

Part 1 - Introduction

ddf – 06/06/2013

Having delt 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 protocal for that plotter. Simply a lot that we nowdays take for granted. Along those same lines, there were growing at an astromical rate a variety of Application Sofware Programs that encompesed 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.:

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:

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)

Return to Main Page (Solutions For Education)