The electronics/logic behind "while(1)" and "for(;;)

5 months ago by printf("%s", name); to c/c_lang

Up until recently, have been trying to validate user input by writing lengthy if-statetments nested in while-loops. I usually have the while-loop check that the function that takes input - for instance getchar() - is not EOF and the if-statement checking whether input is of the desired data type and/or size. But then I noticed people doing something similar with infinite loops while(1) and for(;;).

While I understand that these loops are infinite because there is no condition to check against in for(;;) and because the condition is always true in while(1), I wonder if there is a more pedagogical (?) way of expressing the same thing. Like a proof of concept, or like what's going on at the electronic/logic level, if one were to draw this on a schematic with logic gates.

Or am I perhaps overthinking it and there is "simply" a signal/transistor somewhere that is always on/1/true/has the approproate votlage? Feels like "fooling" the machine by writing while(1) or for (;;) ....

Gladaed 10 points 5 months ago

Programming languages are very far removed from what's actually going on.

You could express the do forever loop as label: startofloop Workload Goto startofloop

If you want the details: you just put the instructions pointer back to the start of loop and get the stack in that state, too.

But the use of goto is generally discouraged. Please note that some programming languages allow the compiler to do anything they want if there is an infinite loop, even texting your ex. (This is for optimization reasons and not maliciousness)

save

path: 0 23932590, hotness: undefined, score: 10, children: 4

akunohana 3 points 5 months ago

Thanks! I know that I sometimes unreasonably obstinately try to link hardware and software in my mind, but that's just my niche... I love the idea, the notion, that some assembler or interpreter at some point gives a CPU instructions in a format that is impractical for humans to read, which then turns into electrical signals. salivating

Thanks for the headsup! I think they cover ex texting in the next chapter of The C Programming Language, Shiny Edition.

save

path: 0 23932590 23932991, hotness: undefined, score: 3, children: 3

owenfromcanada 3 points 5 months ago

It might be helpful to understand the connection between hardware and software better. There are various ways we can create something that a machine can interpret that have evolved over time. We group these into "generations."

Generation 1: writing machine code directly. Either using things like punch cards, or typing in the 1s and 0s directly (more likely hex code, but close enough). This is difficult and error prone, because it's hard for us to make sense of it. So we came up with...

Generation 2: human-readable machine instructions (aka assembly). We write code in something that's easier for us to understand, but it's still explicit instructions to the processor. Then we use a software tool (an assembler) to convert that to machine code. Assembly is still specific to the processor and requires knowledge of exactly what registers are available and such. And then we thought: what if we could write software in a generic way that could work on any processor? So we came up with...

Generation 3: procedural code. With this, we create a new language that is independent of any processor, which means we're not giving direct instructions anymore. Instead, we specify a general procedure, and that generic code is passed through a new tool (a compiler) which converts the generic code to processor-specific instructions. When people say "I'm a programmer" they usually mean Gen 3 programming.

There are additional generations, but this should help provide a background as to why a language like C exists and how it relates to the actual hardware.

A statement like while (1) might not seem terribly elegant, but that's because it probably wasn't anticipated to be a common use case when the language was created. A normal while loop would likely be converted into something like a jnz (jump if not zero) instruction, checking the result of the argument, but any modern compiler would likely convert while(1) to a simple jmp (jump, no conditions) instruction.

I understand your fascination with the point where software and hardware meet. I did my undergrad in electrical engineering, and there was one class where we used a simulator to take transistors (the simplest eletrical "switches"), build logic gates from the transistors, then build processor components like registers and a math processor from the logic gates, then finally a simple calculator out of those components. Super cool.

save

path: 0 23932590 23932991 23936861, hotness: undefined, score: 3, children: 2

akunohana 3 points 5 months ago

Thank you so much for this! You just understood exactly what I meant, felt and what I was wondering about. 😄

That part on generation 3 was especially enlightning, since it finally makes sense to me why there is a compiler "in between" the procedural code and the assembler. Question: does the assembler come somehow embedded with the hardware/CPU and receives the gen 3 code from the compiler, is the assembler packaged with the compiler or is the assembler a part of the operating system?

Thanks for the clarification on how while(1) could be translated into instructions!

I was already interested in the transition from software to hardware, and then that grew into fascination after reading Code: The Hidden Language of Computer Hardware and Software by Charles Petzold.

save

path: 0 23932590 23932991 23936861 23937197, hotness: undefined, score: 3, children: 1

owenfromcanada 3 points 5 months ago

Assemblers can come from the CPU manufacturer, but they can also come from a third party. They're most often bundled into the compiler, since it's rare to need to compile without also assembling (many compilers skip the assembly step and convert directly to machine code). There's actually a third tool involved I didn't mention, which is a Linker (takes pieces of machine code and combines them together, so you can separate your software into different parts).

Some CPUs are more niche, and the assemblers/compilers for them sometimes are created by the manufacturer. But there are a few "standard" processor architectures that many CPUs follow, and because they're common between many brands of CPU (and the architectures are published and well known), the compilers are often created by third parties. And there are some compilers (like gcc) that can compile to dozens of different architectures.

As an example, you might have heard terms like x86, x86_64, armv7, or RISC-V -- these are all processor "architectures", which means that any processor that meets a particular architecture can run machine code built for that architecture. Currently, x86/64 architectures are common among desktops and most laptops (Intel and AMD processors), while ARM architectures are common for tablets and phones and some laptops (Snapdragon processors, for example).

save

path: 0 23932590 23932991 23936861 23937197 23937423, hotness: undefined, score: 3, children: 0

OneCardboardBox 3 points 5 months ago

At some level of abstraction, the end of an infinite loop is just a point where the program counter will never move past. In hardware, this is a kind of branch instruction causing the program counter register to point back to the top of the loop.

Metaphysically, best not to think about it too hard.

save

path: 0 23937118, hotness: undefined, score: 3, children: 0