8
The electronics/logic behind "while(1)" and "for(;;) (piefed.blahaj.zone)
submitted 3 months ago by to c/c_lang@programming.dev
6 comments fedilink hide all child comments
 

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 (;;) ....

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [S] 3 points 3 months ago* (1 child)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [โ€“] 3 points 3 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).

  • permalink
  • fedilink
  • source
  • parent