aykevl
commented
3 years ago I can confirm the issue. I think the issue is that maskSet, maskClear and i are all the constant 8 and the optimizer recognizes this and puts them all in the same register. That would be fine, if the values were indeed treated as constants. But while maskSet and maskClear are constant (and merging them is a good idea), i is not. This leads to the miscompilation.
Right now the inline assembly format does not support marking certain input values as clobbered. I'm not sure whether I really want to add such support, AsmFull is already pretty complicated. Instead, it might be better to move these snippets of inline assembly to C (usable through CGo) so that all the features of GCC style inline assembly can be used (including marking some inputs as clobbered).
CGo might sound expensive, but in TinyGo it's just a regular function call and I have plans of optimizing it further so that it is optimized together with Go code (and can be inlined, etc, see #1707 for some related work).
ewwaller
I think this is a bug in the way inline assembly is processed. I have some code that works properly with the -opt 1 flag, but does not work with the default optimization. The following minimized example includes code from the ws2812 driver. Running on a Adafruit Feather M4, this code displays increasing brightness of red, then green, then blue on the smart LED on that board (AKA Neopixel)
This is done by transmitting three bytes, each encoded as 8 pulses (for a total of 24 pulses) to the device. A narrow pulse codes a 0, and a wide pulse codes a 1
When it works (compiled with -opt 1) , the (correct) output waveform looks like this:
But, with no optimization directive, it looks like this:
In this case, there are initial pulses for each of the three bytes, but the output never goes high for subsequent bits. The time between bytes is the same as had been for the working example.
The tinygo go is :
The inline code uses a register to count of the 8 pulses in a register which is preset to 8 by the wrapping code. The wrapping code also figues out the address of the register to manipulate to control the output and the data that need to be written. All of those are passed into the inline code using the map clause. The wrapping code calls machine functions to get the port information.
Looking at the disassembled code of the working code (-opt 1) for WriteByte we get:
Whereas the optimized, non-working code :
Note that in this case, the optimizer figured out it did not need to call machine as the information was available at compile time, so it used constants. The problem appears to be, in this second case, it is attempting to use the ip register for both the count down from 8 to 0 [ see 0x5daa - 0x5dae], AND as the pointer to the register that contain the I/O register [see 0x5cf8 and 0x5d4a]