keyboard doesn't interrupt infinite loop?

[Paperninja62]

I programmed the IRQ, and GDT, but when i type while an infinite loop is running, it doesn't work, is this supposed to happen or no? here is an example of the code:

Code: Select all

while(thisIsSupposedToBeRunning) {
        //theres nothing here, so i won't have to look through code to see the letter i typed
}
terminal_writestring("Done");

and now, what i originally had was that the while loop would never stop, and i figured since its interrupt based, it would interrupt the loop... this didn't happen..

If you need the source code, be sure to tell me. note, I can normally type, and I'm not reading from a non interrupt port, so I don't see how it sent working

[alexfru]

Check the compiled code (disassembly or use the -c -S options if you're using gcc to see how it converts a .c/c++ file into assembly).

Is the loop in there?

If the loop has no side effects, it may be eliminated by the compiler. Oops.

[iansjack]

What are you expecting to happen when you type? What does your keyboard handler do? And, unless it is supposed somehow to print a character to the screen, how do you know it's not doing what it's supposed to do?

Other than showing us an infinite loop you haven't told us anything.

@alexfru - surely the C compiler wouldn't optimize the loop away. That would fundamentally change the logic of the program, which would make it a very naughty compiler.

[Brendan]

Hi,

@alexfru - surely the C compiler wouldn't optimize the loop away. That would fundamentally change the logic of the program, which would make it a very naughty compiler.

If you do:

Code: Select all

int thisIsSupposedToBeRunning = FALSE;

myTest(void) {
    while(thisIsSupposedToBeRunning) {}
}

Then the compiler can convert it into:

Code: Select all

    cmp [thisIsSupposedToBeRunning],0
    jne .forever
    ret

.forever:
    jmp forever

In this case, if the condition was true then the loop is skipped entirely, and if the condition was false the condition is never tested again.

Of course if you tell the compiler that "thisIsSupposedToBeRunning" is volatile then the compiler can't optimise it like that (it must check the condition within the loop)...


Cheers,

Brendan

[alexfru]

@alexfru - surely the C compiler wouldn't optimize the loop away. That would fundamentally change the logic of the program, which would make it a very naughty compiler.

I wouldn't be so sure. And there indeed are naughty compilers out there, which is why you should probably switch to my Smaller C.

For your personal amusement I include a few relevant links, but sh, don't tell anyone, or we won't get any noob traffic over here!:
http://stackoverflow.com/q/3592557/968261
http://stackoverflow.com/q/15595493/968261
http://blog.regehr.org/archives/140
http://blog.regehr.org/archives/161

[iansjack]

I've tested this with the compiler that I use. With standard optimization the comparison and loop are preserved. With the most aggressive optimization the comparison disappears, but the loop remains. My compiler is not a very naughty compiler.

I probably shouldn't switch to using Smaller C as I'm afraid that it doesn't fare well with 64-bit programs. And when I want to compile stuff for my PI.... (But nice bit of advertising.)

[Icee]

There is no such thing as a naughty compiler. Every decent C compiler available follows the semantics of the C abstract machine which the programmer should do, too. Unless they want broken programs, that is. Without the volatile keyword, the rules dictate that the variable in question can only be changed via a direct assignment or through a pointer assignment in the same thread of control. If the compiler can deduce that there are no such direct assignments in the loop and alias analysis shows that it is impossible for a live pointer written to in the loop to point to the loop control variable, then the loop semantics are that of an infinite loop, so removing it is completely justified.

[iansjack]

the loop semantics are that of an infinite loop, so removing it is completely justified

But the simple fact is that the compiler doesn't remove the loop. I don't blame it - if the programmer wants to write an infinite loop they should be allowed to.

On the other hand, optimizing away the conditional test is entirely justified, and so the compiler does so.

Perhaps the answer is just not to use optimization - but the answer certainly isn't to use a compiler that doesn't even give one that choice because it doesn't do any optimizing in the first place.

[alexfru]

But the simple fact is that the compiler doesn't remove the loop. I don't blame it - if the programmer wants to write an infinite loop they should be allowed to.

And they are allowed to, as long as it's done according to the language specification (the code must have side effects such as accessing volatile objects, modifying a file or calling a function that does any of these).

Perhaps the answer is just not to use optimization - but the answer certainly isn't to use a compiler that doesn't even give one that choice because it doesn't do any optimizing in the first place.

The correct answer is to learn the language well and not write programs with undefined behavior or depending on implementation-defined behavior, unless the specific implementation-defined behavior is known to the programmer, guaranteed by the compiler of choice and desired.

This is a deep hole in C and C++ that spoils the language and makes it unfriendly to learners, especially those not paying attention to details and expecting quick results (I hate those authors who made numerous books like C (or C++) in 21 days, they must burn in hell with all the money earned from these books, they did a great disservice to many programmers). And this hole is not going away, unfortunately. If you don't want "weird" C behavior, either you don't use C or you learn to play by its rules.

[Icee]

the loop semantics are that of an infinite loop, so removing it is completely justified

But the simple fact is that the compiler doesn't remove the loop. I don't blame it - if the programmer wants to write an infinite loop they should be allowed to.

Well, there is clause 6 in 6.8.5 Iteration statements (C11 standard) that says

An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate.

These rules are quite logical if you look from the optimization standpoint. Consider this: why would a programmer write an infinite loop in a way that uses a non-constant expression as its condition? Optimization subsystems in compilers, however advanced they are now, have to be biased: even if there is a huge advantage in removing a block of code or doing some other transformation, if it cannot be proven that these wouldn't change the semantics of the program (as the abstract machine defines it), then the transformation cannot be applied. However, adding into equation the belief that the programmer does not try to fool the compiler opens many more opportunities. Thus this behavior with iteration statement termination in C. There are other places in the standard with the same idea, some of them more obscure. This is the price we pay when coding in C for the extensive optimization possibilities. Other languages have other goals and it's a question of finding the right tool for the job.

[iansjack]

I fear that we are straying too far from the OP. We don't know what compiler he is using or what options he has specified. We don't know what is, or is not, happening when he presses a key (or, indeed, when he does not press a key). We don't even know what he expects to happen. Perhaps it would be better to establish some of these facts rather than wandering off into the more arcane corners of the C language.

[Icee]

I fear that we are straying too far from the OP. We don't know what compiler he is using or what options he has specified. We don't know what is, or is not, happening when he presses a key (or, indeed, when he does not press a key). We don't even know what he expects to happen. Perhaps it would be better to establish some of these facts rather than wandering off into the more arcane corners of the C language.

For all we know, the question could be interpreted as "why does an interrupt not cause a break from a loop". Without further data from the OP, not much can be clarified, and I believe all this to have little to do with compiler options. However, I think it would indeed make sense to split the topic.

[iansjack]

For all we know, the question could be interpreted as "why does an interrupt not cause a break from a loop".

I have a suspicion that it may be that.

[alexfru]

I probably shouldn't switch to using Smaller C as I'm afraid that it doesn't fare well with 64-bit programs.

I have yet to see a hobby OS that would put at least one full gigabyte of memory (virtual or physical) to a good use. I don't get the urge to make a hobby OS 64-bit. Is it hip? Or is it because "yes, we can"? And then there's a plethora of associated issues to solve (quirks of addressing due to 32-bit displacements in instructions, the need to implement multi-level page translation that's not sufficiently regular at all levels, no v86/BIOS, etc). Is it worth it?

[Brendan]

Hi,

I have yet to see a hobby OS that would put at least one full gigabyte of memory (virtual or physical) to a good use. I don't get the urge to make a hobby OS 64-bit. Is it hip? Or is it because "yes, we can"? And then there's a plethora of associated issues to solve (quirks of addressing due to 32-bit displacements in instructions, the need to implement multi-level page translation that's not sufficiently regular at all levels, no v86/BIOS, etc). Is it worth it?

I think often it's the opposite - as soon as you choose "64-bit only" you no longer have to care if the CPU supports FPU, or SSE, or CMOV, or INVLPG, or SYSCALL, or PAE, or .... The same happens for the rest of the hardware (e.g. you can forget about ISA cards, assume PCI exists, assume there's an IO APIC, assume ACPI is supported, etc).

Also note that at least half of your "downsides" are likely to be irrelevant. E.g. these people are using higher level languages and compilers (and have no reason to care about instruction encodings), and are writing OSs that aren't crap (and have no reason to care about v86/BIOS other than in a weeny little boot loader), etc.

I also think people only really care about "recent" hardware. For laptop/desktop/server (where everything has been 64-bit for 10 years now) it's reasonable to ignore 32-bit. Unless someone actually cares about small embedded systems (e.g. Intel's Quark) there's no compelling reason to support 32-bit.

Finally, I'd point out that the biggest benefit of 64-bit is that you get twice as many registers (that are twice as wide), which can make a huge difference to performance in some cases. The additional virtual address space is just a nice little bonus, not a major attraction.


Cheers,

Brendan