http://en.wikipedia.org/wiki/Instruction_set might be a good midpoint to start at. Code compiles to very, very, simple instructions, which are derived from a huge legacy of computing... for example, you mentioned electrons (or "elections", heh), but I started with paper tape storage, which was later related to drum storage, which spawned other kinds of magnetic and chip storage. As an alternate to starting at a midpoint, maybe start at the beginning, and work your way through the history of computing. http://en.wikipedia.org/wiki/History_of_computing It's about 4,000 years long, but to simplify (which is why so many things go abstract), we invented machines that count beads really freaking fast, and then used bead-counting as a way of doing things that didn't, at first, seem to involve counting.
On Tue, Mar 12, 2013 at 7:31 AM, Travisseal <traviss...@gmail.com> wrote: > > Dear enthusiasts, > I am having a rough time visualizing the mechanisms that translate > compiled code into binary instructions. Most resources use very vague > language, like "fetch" and "execute". Although these are primitive > instructions, they are still abstract. How does this "fetch" go about > driving down a bus, picking up elections stored in a memory cells, and > translating them into something useful?(keep in mind hisenburg principal) > Call me faithless, but can someone provide me material that goes this > deep. > > Thank you for reading my sob story. > > Travis > _______________________________________________ > PLUG mailing list > PLUG@lists.pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
