Instance of program : abstract journey from program to CPU (2 ed.)
Tags: computerscience, engineering, programming
Published: 2022-07-06 20:23:00

In one of the recent [posts](https://dev.to/projektorius96/computers-electronics-is-your-body-with-emotions-give-some-hormone-code-see-what-happens--33gd) of mine I did gave a metaphorical approach of computer electronics as a body composed of anatomy & physiology , whereas in this article I'd like to share my comprehension in-real of a program's journey with respect to CPU itself : **_please keep in mind I am learning & reading through many sources on the Internet , including books, lectures, etc., so please correct me if you really think I am on a wrong track_** .

---

In the nutshell, running the instance of a program in-memory we perform mechano-electrical event (action) [rtur, stack exchange](https://cs.stackexchange.com/questions/43336/who-converts-binary-machine-code-to-electrical-signals-and-how) , i.e. by pressing to enter keyboard or so to run the program , upon which we send binary as sequence(s) of electric signal **interruptions** (program’s 1s ask the main circuitry to be interrupted , whilst program’s 0s ask the main circuitry just before CPU execute phase to stay still i.e. be as is) within the constant power in the main circuitry of the computer to be interrupted : herein driven through the main CPU circuitry that has electronic gates variations for each scenario depending on either the signal in the main circuitry was interrupted (to 0, low voltage) or (1, left as is considering computer is of “on” phase for electric signal in the main circuitry) to produce expected (<u>should I say desired ?</u>) result . In simplest terms – programming is about sending interruptions (rather than the wrong approach of thinking that binary is somewhere "converted" to CPU-level instructions) to the main circuitry of CPU  through the CPU’s logic gates, to produce every possible behaviour within limits of hardware that suggests some logic the software can implement , but not vice versa . Saying “but not vice versa” I meant that Engineers design electronics of upon limits programming code will work within, again – but not vice versa, meaning that programming code CAN change behaviour (physiology) of the hardware but not your computer’s anatomy (e.g. hardware parts won't change their places as people can change their seats in the train for a nice(r) view through the window) .

> Since 2 ed.:

Alternatively, imagine you codebase as binary data whereas 1s tells you "hit" (interrupt) a computer circuitry as nervous system of human with Reflex hammer, whilst 0s tells you release reflex hammer i.e. let the computer circuitry flow as is/was . Such interruptions (1s aka switch ON) (0s aka switch OFF) are the "idiomatic conversion" . Different combinations (sequences) of interruptions ensures behavioural diversity of the computer just as different sequences of chemicals producing different hormones will yield different physiology once absorbed by the body .

---

###<u>Articles</u>

- [Fetch-decode-execute](https://en.wikipedia.org/wiki/Instruction_cycle)
- [Microprocessor design handbook](https://en.wikibooks.org/wiki/Microprocessor_Design)
- [Computer engineering fundamentals](https://www.decodingweb.dev/how-a-computer-program-works) | series of article by @lavary