Date: Sun, 24 Jun 2007 15:31:50 +0800 From: "Mark Jayson Alvarez" <mjalvarez@fastmail.fm> To: freebsd-chat@FreeBSD.ORG, mjalvarez@fastmail.fm Subject: Re: Where software meets hardware.. (Hello World program dissected) Message-ID: <1182670310.32703.1196739027@webmail.messagingengine.com> In-Reply-To: <200706211633.l5LGXWvG095148@lurza.secnetix.de> References: <200706211633.l5LGXWvG095148@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
To fully understand things, here's another scenario.
A "Hello World" program. This time I'm going to dissect all
the processes, as far as I can.
Upon boot up, electric charge fills some capacitors in=20
the memory in a certain pattern of "charged and not charged" (1 and 0).
The pattern that was formed points into "another some capacitors" or
addresses
in the memory. This pattern of "charged and not charged" capacitors is
called the "Interrupt Handler Table". "Another some capacitors" are
the actual "Interrupt Handlers"
Back to the "Hello World" program.
Before anything else, first when the computer boots up,
the operating system is loaded into the memory. The operating
system also loads the driver for every device it finds in=20
the computer. All of these are in the form of charged and not charged
capacitor patterns.
"Hello World" program continued...
First, I pressed a series of keys in my keyboard then
electronic current flows into the keyboard port attached
to the motherboard. Then this port has a circuit connected
to a particular pin in the CPU. Then the CPU upon getting
interrupted by the electronic current that has arrived into
this particular pin, through some sort of transistors/capacitor magic,
accesses the "Interrupt Handler Table" in the memory and look up the
address
that points into the actual "Interrupt Handler" for the keyboard.
Now that "Interrupt Handler" is also a pattern of "Charged and not
charged"
capacitors which represents a binary driver written to the memory=20
by the operating system upon bootup.=20
The processor does all its machine codes stuffs to dissect and process
this keyboard driver via an Operating System routine, store the result
first into
its register and then write it back to the RAM, return the execution and=20
the results back to the operating system routine that called the driver.
Now the operating system knows that I have actually pressed some keys in=20
the keyboard and do the same processes to echoed everything that I have
typed into the monitor and also write it on the surface of my hard=20
drive using magnetism.
Everthing that I have typed, echoed into the monitor, and got written
into the surface of my hard drive looks like:
#include <stdio.h>
main()
{
for(;;)
{=20
printf ("Hello World!\n");
}
}
Now I run the compiler, read the above series of
characters which are written on the surface of my hard drive
as pattern of 1's and 0's or "magnetized and not magnetized =3D)"
and write everything back into a binary format or a pattern of
1's and 0's, again??
The process of actually executing the routine in the Operating system
that writes these binary code into the memory for the processor to
process
and run it, is actually running the program itself.
Things are more clearer now. It's all about electric charges, either
"on" or "off".
The most essential parts are the processor and the memory. The processor
do
all the processing using some sort of transistors and capacitors magic.
Everything
that gets processed are written by the processor into the memory in a
form of=20
electronically charged and not charged capacitors.
The only confusing thing that is left is that binary format thing. I
thought everything
that is written in the hard drive is already a series of 1's and 0's. If
I compile
the program, it is converted into a machine readable format or a binary
format.=20
What's the physical difference of binary and non binary format?? The
only difference
I can see is that when I open the non binary format in an editor, it is
quite readable
unlike the binary format which is full of mixed and unrecognizable
characters.
Thanks for the time.
-jay
On Thu, 21 Jun 2007 18:33:32 +0200 (CEST), "Oliver Fromme"
<olli@lurza.secnetix.de> said:
> Mark Jayson Alvarez wrote:
> > Let's say I have a very simple washing machine program.
> > Now it has a timer which the duration of the spinning can be set.
> > If I press the 3-minute button, wires beneath will get shorted.
> > Electric current will flow into pin number 5 of the parallel cable
> > connected to the parallel port of my PC. Now the CPU has a pin
> > connected to this port. If it receives let's say 5V, it will stop
> > what it's doing and=20
> >=20
> > > fetches the
> > > address of an "interrupt handler routine" from memory,
> > > and jumps to that address (i.e. starts executing
> > > instructions from that address). That handler is
> > > usually installed in memory by the operating system.
> > > The code checks which device caused the interrupt,
> > > and then executes the appropriate routine in the
> > > corresponding device driver.
> >=20
> > And when exactly did the Operating system installed this interrupt
> > handler??
>=20
> When it boots. The processor supports an interrupt
> handler address table. That's simply a list of memory
> addresses which is itself stored in memory. Each
> kind of interrupt (they're numbered) has an entry
> in that table that points to the appropriate interrupt
> handler which has been installed by the OS upon boot.
>=20
> For example, let's say interrupt line 7 is connected
> to the parallel port. So when the processer receives
> a signal on that line, it looks up the address that
> is stored in entry #7 in the interrupt table. Then
> it will execute commands at that memory address, and
> afterwards it will resume whatever was interupted.
>=20
> > And suppose this handler runs the driver and the=20
> > appropriate routine inside it, how did the driver able to convert the
> > electric
> > current into a machine understandable data and was able to pass it
> > to a program and the program receive the data as 3 minutes?
>=20
> It depends. If you have one interrupt per button,
> then there's a one-to-one relation ship between
> buttons and interrupt numbers. So if you press
> that 3-minutes-button, let's say it's connected to
> interrupt pin #7, so the processor will run the
> handler that has been registered for interrupt #7.
> That handler is specific to that interrupt and to
> that button, so it "knows" that the 3-minutes-button
> has been pressed when it is called (because that's
> why it was installed for the interrupt in the first
> place). There is no need for the driver to "convert
> the electric current". The handler is called as a
> reaction to the interrupt signal, and that reaction
> in itself contains the information about the press
> of the button.
>=20
> However -- normally you don't have one interrupt
> per button, but rather one interrupt per device.
> Having one interrupt per key (on a keyboard) would
> be very inefficient. Instead, there is one interrupt
> for the whole keyboard (or for all the buttons on a
> device). So, any button press will cause the same
> handler to be executed. The device driver routine
> knows that a button has been pressed, but it still
> has to find out which one. How does it do that?
>=20
> Well, in simple cases (like embedded systems in a
> washing machine), the electrical lines from the
> buttons are connected to I/O pins on the processor,
> or on separate I/O chip which is connected to the
> actual processor. Basically this is similar to an
> interrupt line, in that it causes a pin to go from
> 0 V to 5 V (or whatever voltage levels are used).
> But the difference is that it does not cause an
> interrupt to occur. The processor simply ignores
> those I/O pins during normal operation. However,
> the processor supports machine codes that can read
> the current state of the I/O pins. If the processor
> executes such a code (i.e. a certain byte sequence),
> it copies the current state of the I/O pins into a
> register, where it can be dissected and examined
> with other machine instructions. That state is
> usually encoded in a binary format, where each bit
> corresponds to one I/O pin. A single byte has 8 bit,
> so it can contain the information of 8 such I/O pins.
> If a pin is 0 V, the corresponding bit is 0,
> otherwise it is 1.
>=20
> > Driver is just a software right?
>=20
> Right.
>=20
> > I'm sure if I can find out how electric current have been actually
> > converted into 1's and 0's I will not have trouble understanding
> > how it can be converted the other way around.
>=20
> Actually nothing needs to be converted. "0" and "1"
> are just interpretations of different voltage levels.
>=20
> > It has something to do with registers right? What are this
> > registers looks like? A microchip that can get written using
> > electric current?
>=20
> Processor register are simply small pieces of memory
> inside the processor. They are required for the
> processor to perform calculations and other things,
> because they cannot be performed directly in RAM.
> In order to do anything with data stored in RAM, the
> processor has to load values into registers, and
> when it's done, the result have to be stored back
> into RAM.
>=20
> For example, in order to add two numbers that are
> stored in memory, the processor loads both of them
> into two of its registers. Once they're there, they
> are added by the ALU (=3D=3D arithmetic-logial unit,
> part of the processor), and the result is again
> stored in a register. Then the contents of that
> register are written back to main memory.
>=20
> > What are these 1's and 0's look like anyway? How are they written in t=
he
> > memory? A chemical reaction when electric current flows into the ram?
>=20
> No, it's all electrophysical, not chemical. Well, a
> "1" usually looks like 0 V, and a "1" looks like 5V
> (or 3 V or whatever). Inside electronic components
> such as processors, RAM, graphics and network cards
> etc., bits are almost always represented as voltage
> levels.
>=20
> > Data that is written in the RAM differs the way they are written in a
> > hard drive or a CD right? But the truth is they are all 1's and 0's?
>=20
> Yes. All media (RAM, flash, disks, tapes, CD, DVD
> and even punch cards) have in common that they store
> data as "0" or "1" in one form or another. The
> important property is that the media is capable of
> having two distinct states, so one of the states is
> assigned the "0" value and the other the "1" value.
>=20
> For example, CDs have tiny "pits" on the surface.
> A laser beam measures the width of those pits (small
> ones and large ones), and a DSP converts that into a
> sequence of "0" and "1".
>=20
> On hard disks the same information is stored using
> magnetism. RAM (DRAM =3D=3D dynamic RAM) uses tiny
> capacitors to hold a very small electric charge that
> represents the bit value.
>=20
> If you want to know more details about how a processor
> access data in memory, how address bus and data bus
> works, how a processor is built up from transistor
> functions, I strongly recommend that you buy a good
> beginners book of processor design.
>=20
> I remember at school we've built simple electronic
> components ourselves: a flipflop (that's a simple
> 1-bit memory) from two transistors, logical gates
> (i.e. "and", "or", "not" circuits), bit counters,
> adders and similar things. At that time that was
> very enlightening for me. I suggest you try
> something like that, too. You can buy electronic
> construction and experimentation kits at toy shops.
> Don't be afraid that they're intended for children,
> I know quite some adults who play with things like
> that once in a while, including myself. :-)
>=20
> Best regards
> Oliver
>=20
> --=20
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehrun=
g:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC=
n-
> chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb=
hart
>=20
> FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
>=20
> "C++ is the only current language making COBOL look good."
> -- Bertrand Meyer
--=20
Mark Jayson Alvarez
mjalvarez@fastmail.fm
--=20
http://www.fastmail.fm - Choose from over 50 domains or use your own
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1182670310.32703.1196739027>