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
Post a Comment