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

> 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.

And when exactly did the Operating system installed this interrupt
handler?? And suppose this handler runs the driver and the=20
appropriate routine inside it, how did the driver able to convert the
current into a machine understandable data and was able to pass it
to a program and the program receive the data as 3 minutes?
Driver is just a software right? This part is what really confuses me.=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. It has something to
do with registers right? What are this registers looks like? A microchip
that can get written using electric current?

What are these 1's and 0's look like anyway? How are they written in the
memory? A chemical reaction when electric current flows into the ram?
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?

Thanks you very much!


On Thu, 21 Jun 2007 14:33:56 +0200 (CEST), "Oliver Fromme"
> Mark Jayson Alvarez wrote:
> > Good day! I could have sent this to questions@freebsd.org but I know
> > it will get treated as irrelevant topic as well. Just trying my luck
> > here though.

> Actually this is most appropriate on the "chat" list.
> I've redirected replies there.
> > I have a cousin who's taking up a programming course. He doesn't have
> > background with programming nor an in depth understanding of how the
> > computer works. I tried explaining him that it all started with
> > abacus, and that people wanted to use something that could make their
> > arithmetic life easier and that Charles Babbage tried automating this
> > manual calculator with his steam engine or some sort... and that...

> Actually Charles Babbage designed a complex mechanical
> computing machine (with lots of gearwheels etc.), but
> it only ever existed on paper. Only small parts of it
> have actually been built, but never the whole thing,
> because it was too complex. It would work in theory,
> though. :-)
> > This is how my programming teacher explains how a program gets
> > executed. First you compile it into a machine readable code, then
> > the operating system writes it in the memory, and finally the CPU
> > fetches it and it finally gets toasted by the electricity flowing on
> > the CPU's surface. It doesn't make things clearer though.:-(

> That's pretty close to the truth, actually.
> > I really don't get it. Can you in a very simple sentence explain to
> > me how and where a software program

> I'm afraid the interactions between memory, processor
> (CPU) and software is a complex thing which cannot be
> explained in a single simple sentence. I'll try to
> explain a bit ...
> A processor is able to execute instructions which are
> called "machine code". Basically it's a sequence of
> bytes stored in memory (RAM). The processor fetches
> byte after byte from memory and executes the commands
> that they represent. Such commands include: "load
> a number from memory into a processor register", or
> "add these two processor registers and store the result
> in memory", or "check whether this value is zero, and
> if it is, then jump to a specified address in memory
> instead of continuing with the following instruction".
> It's possible to have loops, subroutines, interrupt
> routines and other things, but the details aren't
> important in order to get a basic understanding.
> Of course, most programmers don't write that machine
> code directly. It's efficient for the processor to
> execute, but it's inconvenient for a human programmer
> to write. A programmer usually writes programs in a
> higher-level language, such as C. Then a tool called
> compiler is used to convert that "source code" into
> "machine code" that can be executed by the processor.
> The result is an executable file stored on disk (also
> called a "binary").
> When a binary is about to be executed, the operating
> system (such as FreeBSD) loads it from disk into RAM
> where its byte stream can be executed by the processor.
> Of course in reality it's more complicated, but the
> above are the very basic and low-level things that
> happen.
> Device drivers are somewhat different. They're normal
> binaries, too (usually compiled from source code, too),
> but they're loaded once when the operating system boots
> the computer, or once when the appropriate kernel
> module is loaded. Many device drivers are interrupt-
> driven. When an external event occurs, such as a
> packet arriving on a network interface, or the user
> pressing a key on the keyboard, the hardware device
> signals an interrupt to the processor (basically a
> connector pin on the processor is set from "low" to
> "high", i.e. from 0 V to 5 V or similar). The processor
> stops whatever it is doing right now, 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. When it's finished,
> a "return" instruction is executed, which causes the
> processor to resume whatever it was doing before the
> interrupt occured.
> > Does it have anything to do with the bios?

> The BIOS is also simply a piece of software, stored
> in a chip on the mainboard. It initializes the hard-
> ware right after the machine is switched on, and
> arranges for the operating system to be booted from
> the disk (or from other kind of media if supported).
> After the operating system takes control of the box,
> the BIOS is not used anymore at all. (There are
> certain exceptions, but lets forget about them for
> now.)
> Booting is usually a multi-stage process, i.e. first
> the BIOS loads a tiny boot loader from the first
> sector of the disk (the MBR =3D=3D master boot record),
> then the code contained in the MBR loads the
> operating system's first stage boot loader and so
> on. All of those stages still use BIOS routines
> to access the disk. The last stage (in FreeBSD
> that's /boot/loader) loads the actual OS, i.e. the
> kernel and modules that are required to boot the OS.
> The kernel has its own device drivers for disks and
> other media, so it doesn't use the BIOS anymore.
> > I told my cousin, that someday he will be a real programmer and that
> > even if he will be dealing only with java, html, animation and all
> > sorts of high level programming stuffs,

> It should be pointed out that HTML is not a programming
> language. ;-)
> > in the spirit of open source (and freebsd of course), it's better
> > that he knows exactly how a program interacts with the physical
> > computer.

> Well ... It depends. As a high-level programmer, it
> is good to know how machine code works and how the
> compiler generates it, because it also enables you
> to write more efficient programs. That's especially
> true for kernel source and device drivers.
> On the other hand, both processors and compilers
> become more and more complex and advanced, and newly
> designed higher-level languages (such as Python)
> increase the "distance" between machine code and the
> source code that people write, so there is less
> relationship.
> Therefore I think that nowadays it is more important
> to learn software design, how to develop efficient
> algorithms, learn a bit about computational complexity
> (for example, when and why is quicksort faster than
> bubblesort) etc.
> At university there was a teacher who said that you
> should learn as many different programming languages
> as possible, at least one of every kind, i.e. one of
> the "classical brace languages", such as C, at least
> one object-oriented language (e.g. Smalltalk, Eiffel),
> one functional language (Haskell or OCaml), one
> assembly language (no matter which one) and so on.
> The more the better.
> Best regards
> Oliver
> --=20
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehrun=

> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC=

> chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb=

> FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
> "With sufficient thrust, pigs fly just fine. However, this
> is not necessarily a good idea. It is hard to be sure where
> they are going to land, and it could be dangerous sitting
> under them as they fly overhead." -- RFC 1925

Mark Jayson Alvarez

http://www.fastmail.fm - Accessible with your email software=0D
or over the web

freebsd-chat@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-chat-unsubscribe@freebsd.org"