Yes, you are right that a post-increment in a switch statement is no differently than elsewhere. The goal I had set was to implement a small easy to read C compiler. For that reason I tried to implement it as a single pass compiler that would generate code on the fly. The target was a small stack based language, which did support variable scoping and gotos, but not a switch. My first attempt was to implement the switch statement with chained if-statements where the switch expression would be evaluate over and over again. This only works if the switch expression did not have side effects and that the 'default' case would always come at the end. But that did not work, so I had to come up with another solution, a solution that would only evaluate the switch expression once. I decided to store the value on the stack and duplicate the value whenever needed for comparison. But that would require the value to be popped once a case was selected. A goto jumping from one case to another should land after the location where the value is popped, otherwise it would corrupt the stack. I fear that this solution does not work correctly when a case occurs within a for, while, do-loop, or if-statement. cases may occur everywhere in the enclosed code. This is sometimes used to emulate co-routines or generator functions.
Did you know that C has a keyword that is only a keyword in some places and that there is a function that can have two or three parameters?
Maybe the strategy from TCC itself is useful here: emit case bodies as a giant block first then jump back with cascaded if's at end. https://godbolt.org/z/TdE11jjxb
> Did you know that C has a keyword that is only a keyword in some places and that there is a function that can have two or three parameters?
defined is a pre-processor 'keyword' that only is used in conditions after #if and #elif. Elsewhere it is ignored by the pre-processor. You could argue that it is not a real keyword. But lets see what happens when you define it as a define with: '#define defined 1'.
The function main can be defined with two or three parameters. The third contains the environment. You can also get the environment with 'argv + (argc + 1)'.
Given the current upper bound on legal chess positions is 7.7e45 ≈ 152.4 bits, you either have found a better upper bound or your memory doesn't serve.
They didn't try to encode all legal positions though, only ones that were actually reached in their database of games. It sounds very plausible to me that this allows a lot of simplifying assumptions that cut the state space by about 60 bits
I can put it all in, say, 24 bits, if my database is small. 140k games, 120 positions each. log(140000*120)/log(2) ~~ 24.001, and surely there will be some duplication.
The encoding is just the index number of the game + move that resulted in that position.
From the stats we see that most bugs effectively come from the limitations of the language.
Impressive results on the model, I'm surprised they improved it with very simple heuristics. Hopefully this tool will be made available to the kernel developers and integrated to the workflow.
I couldn't find much on training AI models. Apparently GPT-3 used 1.3 GWh for training. So maybe ~10 GWh for newer models?
So... let's stop training humans I guess.
reply