The Mystery of Creation: Chapter 3: Understanding the Trinity: Understanding Computers


Understanding Computers
                So let’s begin with computers.  How do computers work?  Energy passes into the computer from your wall outlet or from a battery when you press the power button.  Immediately after receiving power, the Central Processing Unit, CPU for short, begins processing computer commands which are written in computer code (or programming). 
                Usually the computer has a startup list of commands it obeys based on what its operating system is.  First it loads this program and then it loads that one, and so on.  Finally, the lock screen appears allowing you to finally do something.  The lock screen only appears because the computer has finished executing the commands it has written up for it in its startup list, and the lock screen is only the last, or one of the last, commands that it has executed.  (Most of the time the computer is still executing commands on its startup list even after it allows you to access your lock screen, but you don’t notice because you only focus on what YOU are able to access.  This is why you might sometimes have difficulties logging in at first to your system.  The computer is hung up still on completing its startup list of tasks even after giving you access, and once you’ve entered your login data it has put your task at the bottom of the list of tasks it is still completing.  So the system might freeze on you for a few seconds, or thirty…or even a minute…depending on how fast your computer is…while it finishes up that list of tasks before it finally gets to your login information and processes it to let you into the system.)
                The CPU is divided into two different units.  The first unit is the arithmetic/logic unit, or ALU.  The second is the control unit.  The ALU is like the CEO of a company.  The control unit is like the CEO’s Administrative Assistant.  Like an Administrative Assistant who goes into the filing system to pull up the CEO’s schedule for the day, when you start your computer, the control unit grabs the startup list from the computer’s memory.  It then sends that startup list to the ALU who, like a CEO, arranges all of the tasks, prioritizing them by order of importance.  First the computer will load up this file and then that file, and so on. 
                The ALU then gives its orders to the control unit who then delivers these orders to the various parts of the computer.  These parts then obey the orders given to them based on the priority that the ALU has put all of the commands in.  When a user, then, interacts with the computer, the control unit delivers the input from the user to the ALU and the ALU translates the user’s input into a command that the computer can execute.  It prioritizes the user’s action, treating it like a customer, and then it gives the orders back to the control unit to deliver to whatever part of the computer is affected by the user’s request.
                Let’s put this into an example.  Let’s say you are using a tablet or smartphone.  You touch an app to open it.  What happens in the computer?  The moment you touch the app icon on your screen you issue a command to the computer inside your phone or tablet.  This command was written by a computer programmer.  The command states something like this, “If someone touches this icon on their screen then start up this app.” 
                The control unit, within the phone or tablet, receives this command from the sensors in your touchscreen.  The control unit then transmits this command to the ALU.  The ALU then receives the command and determines whether it can and should obey this command and whether it needs to prioritize this command behind another program that is already running.  If it doesn’t understand the command, then it will not execute the command or it may try to execute the command the best way that it knows how.  If it does understand the command then it will prioritize it along with all of the other commands that it is executing.
                Most of the time the app immediately starts up because your smartphone or tablet are programmed to obey user commands above all other commands.  So your tablet or phone will do everything it can to start up that app because you ordered it to and because that is how it is programmed to respond to user commands.  It will put other commands on hold until your app is loaded because it prioritizes user commands above a lot of other commands that are running in the system.
                However, apps and programs glitch or crash.  Glitches are events that occur within a computer where it functions in an unexpected manner.  In video games, glitches can be anything from a character falling through a solid floor or wall, to flying through the air, to a hand passing through a person’s body, to a person being behind a desk and then suddenly being in an entirely different room for no reason at all, or any number of other such weird situations. 
                Crashes are when the system completely freaks out and you have to reboot to get it to work again.  Programs and apps crash and sometimes you are just put right back to your home screen or desktop.  Other times when they crash you have to reboot your entire system.  Why do these things happen?
                There are several reasons why computers glitch or crash.  One is because the ALU has determined that something else is more important than that app that you want to run.  Another is because two or more apps are trying to use the same resource, like your screen, at the same time, and the ALU doesn’t know which should take priority over the other.  The programming within the ALU that tells it which program should take priority does not include the situation it has been presented with.  Therefore, it tries to run both at the same time and so weird things happen.  Finally, apps and programs often glitch because the ALU doesn’t understand the command that was given at all.  The result is usually that the computer will glitch because it is trying to obey the command it was given to the best of its abilities, but because it has not understood the command, or another program or resource is getting in the way, it can only partially obey that command or it just freezes up because it doesn’t know what to do at all.
                Using a video game as an example, if the programmer has put code into the computer stating that a wall cannot be passed through by a character then if the user tries to command his character to go through that wall the programming will prevent it.  The control unit sends the command from the user to the ALU and the ALU says, “No.  That character can’t go through that wall.”  Then the control unit transmits the command to the monitor and tells the monitor to display an image of the character running into the wall but not passing through it. 
                However, if the user tells his character to swing his sword at the wall, by hitting a button on his controller, if the programming does not say one way or the other whether the sword can pass through that wall, the ALU will not know what to do with the image of the sword when it comes into contact with the image of the wall.  Because there is no programming to tell it what to display once the sword hits the wall, the ALU may tell the control unit to do something weird like, “Have the monitor display an image where the wall temporarily vanishes and the sword is seen passing through the wall as if the wall is transparent.”  It may even have the sword bend at a weird angle when it connects to the wall or it may simply vanish as it comes into contact with the wall.  Because the programming is not there, the ALU doesn’t understand the command and therefore does whatever it thinks is best on the screen to try to fulfill the order given by the user.

Comments

Popular Posts