| Why do compilers even bother with exploiting undefinedness signed overflow? And what are those | |
| mysterious cases where it helps? | |
| A lot of people (myself included) are against transforms that aggressively exploit undefined behavior, but | |
| I think it's useful to know what compiler writers are accomplishing by this. | |
| TL;DR: C doesn't work very well if int!=register width, but (for backwards compat) int is 32-bit on all | |
| major 64-bit targets, and this causes quite hairy problems for code generation and optimization in some | |
| fairly common cases. The signed overflow UB exploitation is an attempt to work around this. |
| /* ======================================================================== | |
| $File: tools/ctime/ctime.c $ | |
| $Date: 2016/05/08 04:16:55PM $ | |
| $Revision: 7 $ | |
| $Creator: Casey Muratori $ | |
| $Notice: | |
| The author of this software MAKES NO WARRANTY as to the RELIABILITY, | |
| SUITABILITY, or USABILITY of this software. USE IT AT YOUR OWN RISK. |
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
| public enum Direction { | |
| case forward | |
| case backward | |
| } | |
| internal var player: AVPlayer? | |
| private var isSeekInProgress = false | |
| private var chaseTime = kCMTimeZero | |
| private var preferredFrameRate: Float = 23.98 |
As C programmers, most of us think of pointer arithmetic for multi-dimensional arrays in a nested way:
The address for a 1-dimensional array is base + x.
The address for a 2-dimensional array is base + x + y*x_size for row-major layout and base + y + x*y_size for column-major layout.
The address for a 3-dimensional array is base + x + (y + z*y_size)*x_size for row-column-major layout.
And so on.
This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.
It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.
Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2
The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and