2

What are the steps taken by the CPU to sum 2 numbers(2+2) from the keyboard input to the display in the screen?

example: reading the ascii code .... convert the typed number to binary ... send to cpu .... printing on screen?

26
  • 6
    To close voters: please don't VTC this as "unclear what you're asking." Just because you don't understand basic compiler theory doesn't mean this question isn't absolutely clear to those of us who do. – Mason Wheeler Jan 20 '17 at 20:28
  • 5
    @MasonWheeler: i will VTC because it is incredibly broad though. – whatsisname Jan 20 '17 at 20:36
  • 6
    What is wrong with you people? We have someone here who wants to learn and simply doesn't know where to start, and you deny anyone even the opportunity to point him in the right direction?!? – Mason Wheeler Jan 20 '17 at 20:40
  • 3
    I'm inclined to believe that as is, this question is indeed much too broad (does OP want high level pseudocode, low level (pseudo)assembly, or machine code? cpu only or cpu + peripherals?), but should be fixable. I'm inclined to believe it's probably on topic, as understanding what's going on with code can be useful in writing it, though depending on how clarification goes (if at all), it may turn out to be off topic. – 8bittree Jan 20 '17 at 20:58
  • 5
    "from the keyboard input" makes this a gigantic question – Richard Tingle Jan 22 '17 at 22:28
3

The "higher level" steps are as you've guessed: Get characters from keyboard, convert to integers, add the integers, convert the result back to characters, then display those characters.

The CPU does none of this itself.

The CPU executes tiny little instructions that each do a very simple (and very specific) thing. These instructions are the fundamental (lowest level) building blocks of software. Each of those high level steps represents many instructions.

For a detailed example; to get 1 character from the keyboard (using multiple assumptions about the computer's hardware and the OS being used and over-simplifying):

  • Some sort of controller (that the keyboard is connected to) will send an IRQ (Interrupt ReQuest) to the CPU, and the CPU will (sooner or later) respond by starting an interrupt handler.
  • The OS's interrupt handler will figure out what the IRQ was and invoke a device driver's interrupt handler
  • The device driver's interrupt handler will do whatever it has to to get the byte from the controller (this can be several layers of "complex" for some cases - e.g. USB). Then it'll send that byte to a keyboard driver
  • The keyboard driver will figure out a "scan code", which typically involves a state machine to figure out if multiple bytes are part of the same scan code (or part of a new scan code). Then it will typically convert the "potentially multi-byte scan-code" into a "fixed size integer key-code".
  • Then the keyboard driver will use the key-code and various lookup tables and other meta-data (that depend on which keyboard layout is being used) to determine if there is/isn't a "character" (Unicode codepoint?) associated with that key. Note that a lot of keys simply don't have any character.
  • The keyboard driver will combine this with other information to form some sort of "key press event"; and send that event somewhere (e.g. to a GUI).
  • The "key press event" will make its way through various processes (e.g. from X to GUI to terminal emulator to shell to foreground console app) until it finds its way to an application. This can involve stripping a lot of useful information at some point (terminal emulator) to make it work for legacy stdin.
  • Once the key/character arrives at the application; there's typically some sort of input buffering that allows the user to edit (and supports things like backspace, delete, cursor movement, cut/copy/paste, etc). Also; the "current buffer" is typically being displayed while the user edits it (so that they can see what they're doing). Usually, when the user presses "enter" the entered text is considered complete. This may all be done by a library (e.g. C standard library).
  • Then application determines if the input is valid. E.g. if it's expecting a string representing a number but the user typed "FOO" then it may (should) display an appropriate error message and reject the input.
  • While doing input validation, or after doing input validation, (or instead of doing input validation for extremely bad software), the application converts the input text (a string representing a number) into an integer

Note that all of the above can easily add up to thousands of tiny little instructions that are executed by the CPU; even though it's only a fraction (barely more than one of the "higher level steps" we started with) and even though I didn't provide any details of how the input buffer is displayed while it's being edited (font engine, text layout engine, 2D graphics renderer).

For all higher level steps (get 2 numbers from user, add them, then display the result) the total number of instructions that a CPU executes can be (literally) millions.

7
  • 1
    "convert to integers, add the integers, convert the result back to characters" - The CPU almost certainly directly performs all the instructions necessary for these three tasks. These three tasks are also much simpler than the I/O tasks. The actual work for all three of these combined is not more than a few dozen instructions and can be done entirely in user space, meaning no extra complexity from calling into the kernel, and even calling into a library for the conversions doesn't necessarily add much more than a few pushes, a call and a return. – 8bittree Jan 23 '17 at 15:06
  • @8bittree: Ignoring all the work that a library function does (and only caring about the instructions used to call the library function) does not give a complete picture of "the steps/instructions a CPU actually does". – Brendan Jan 25 '17 at 1:56
  • I didn't say anything about ignoring the work done by a library function. In fact, I specifically mentioned the extra work that using a library function, rather than your own code, would add. – 8bittree Jan 25 '17 at 2:01
  • @8bittree: In that case, (except for pointless "splitting hairs" - e.g. "CPU doesn't do each high level step" vs. "CPU does all the tiny little steps that make up a high level step") I have no idea what the point of your comment was. – Brendan Jan 25 '17 at 3:40
  • There were two things that I was addressing in my comment: 1) Your statement "The CPU does none of this itself" seems to imply, at least to me, that it offloads all those tasks to a co-processor or external device, which is rarely, if ever, the case for the three tasks I quoted in my original comment. 2) You're not explicit about it, but in several places, you seem to imply that those same three steps are roughly equivalent in complexity to the I/O steps, and need thousands or millions of instructions to complete, which is a gross misrepresentation of the complexity of those three steps. – 8bittree Jan 25 '17 at 22:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.