2 ms·
I certainly don't understand what you're trying to say, and replying with four words definitely won't help me. Perhaps there's some confusion of what a runtime
by nomel 5y ago
I certainly don't understand what you're trying to say, and replying with four words definitely won't help me.
Perhaps there's some confusion of what a runtime check is. A runtime check is executed at runtime, which means that it will be executed after compilation with a specific compiler, on a specific architecture, in the end user system. The runtime check verifies correct struct operations at runtime, as part of the initialization, and aborts the driver load, with a nice system message, if improper packed struct behavior (among other things) is seen. This covers your concern here:
> Unless your code will only ever run on that exact machine, you have not tested it.
It literally is tested on every machine, when the driver is loaded.
This runtime check handles the cases where a customer might try to run it on some new hardware/toolchain that we don't officially support. The official supported cases only have risk of new compiler bugs, since we only support certain architectures. Hypothetical compiler bugs are a problem for all software, and shouldn't be used to drive software design, beyond making sure there is good testing, which has nothing to do with compilers.
Maybe I'm missing something.
edit: ncmncm, I can't reply to you, but since I have code that does what you say is impossible, and since my comment already responds to what you wrote, I would suggest reading all of my comments, fully, a second time.
- ncmncm 5y agoYes. You will never have a startup test of all the instructions used, in all the circumstances where they are used. Startup tests are useful for checking the presence or absence of certain advertised features, such as SIMD instructions. They are useless for buggy compilers and buggy chip implementations. And, what would the code do if it detected such a bug? Abort, or run other code that works OK anyway. So, run that code all the time, and you don't need to try to check.
- Gibbon1 5y agoOn an AVR if you write this in C PORTB |= (1<<4); You get this in assembly sbi PORTB, PINB4 However if you write PORTB = PORTB | (1<<4)l The compiler instead emits. sbi PORTB, PINB4 I ported some code once where they went to the trouble of defining the registers as bit fields. In that case portb.pin4 = 1; compiled to sbi PORTB, PINB4
- ncmncm 5y agoIf you are doing full functional tests of your ROM app on on each mask stepping before it is soldered into thousands of boards, congratulations, the warning isn't for you. amd64 bugs tend to be in newer parts of the ISA. ARM provides chip makers very thorough tests, to protect their brand (though not all chip makers fix all the bugs tests find). So, many programmers will not encounter bitfield bugs. But code gets around, and tests are always less thorough than we wish.
- nomel 5y agoMaybe I'm naive, but I don't see why fully functional runtime tests are required. The only purpose of a runtime tests is to test things that could vary, at runtime, like architectural incompatibilities, with memory layout things like endianness and bitfields being an example. These are trivial to implement in a few dozen bytes. If you have a ROM soldered into boards, then absolutely none of this would be a concern since the architecture would be intimately known, so I'm now completely lost on your point. Anyways, cheers!