3 ms·

Weird ISAs are exactly why you cannot compare pointers. Segmented memory for one. Or imagine an OS and compiler that implemented automatic overlay switching. Wi

by zlynx 8y ago

Weird ISAs are exactly why you cannot compare pointers. Segmented memory for one. Or imagine an OS and compiler that implemented automatic overlay switching. With that and PAE on 32-bit x86 systems you could have special "far overlay" pointers returned from malloc calls which would map in different 1 GB overlay sections when accessed. Aliasing rules are important in some ISAs too. Like weird DSPs. Imagine a system where 32-bit objects can't even share the same memory space as 8-bit objects. Casting a pointer to a different sized type is completely meaningless there. Of course programming such a weird thing is usually done in assembly, but there are C compilers.

cryptonector 8y ago
I'm not familiar enough with C on segmented architectures, so I can't quite speak to that, but I was referring to [0], which clearly has nothing to do with segmented architectures. As to aliasing, ISAs too had nothing to do with the reason for aliasing rules, but rather optimizations for functions like memcpy() (as opposed to memmove()). [0] https://news.ycombinator.com/item?id=17439467 https://news.ycombinator.com/item?id=17439467
- mattnewport 8y ago
  There are other aliasing rules that have big performance impacts on certain architectures. The Xbox 360 and PS3 Power cores for example had a severe load-hit-store performance penalty that tended to be triggered by code that moved data between floating point and integer registers via memory. Strict aliasing rules that allow the compiler to assume float and int pointers don't alias could make a huge performance difference but those rules are also the source of much troublesome undefined behavior for code that does intentional type punning. The ISA in this case requires going via memory to move data between fp and integer registers and certain implementations of that ISA had major performance impacts associated with that. In this case UB rules really did allow for valuable optimizations but really did cause trouble elsewhere.
  - cryptonector 8y ago
    The ISA you describe doesn't require aliasing rules. It merely gives you an incentive to have them. C and other languages need much better control over aliasing than the 'restrict' keyword and compiler command-line switches.

by zlynx 8y ago

cryptonector 8y ago

I'm not familiar enough with C on segmented architectures, so I can't quite speak to that, but I was referring to [0], which clearly has nothing to do with segmented architectures. As to aliasing, ISAs too had nothing to do with the reason for aliasing rules, but rather optimizations for functions like memcpy() (as opposed to memmove()). [0] https://news.ycombinator.com/item?id=17439467 https://news.ycombinator.com/item?id=17439467

mattnewport 8y ago
There are other aliasing rules that have big performance impacts on certain architectures. The Xbox 360 and PS3 Power cores for example had a severe load-hit-store performance penalty that tended to be triggered by code that moved data between floating point and integer registers via memory. Strict aliasing rules that allow the compiler to assume float and int pointers don't alias could make a huge performance difference but those rules are also the source of much troublesome undefined behavior for code that does intentional type punning. The ISA in this case requires going via memory to move data between fp and integer registers and certain implementations of that ISA had major performance impacts associated with that. In this case UB rules really did allow for valuable optimizations but really did cause trouble elsewhere.
- cryptonector 8y ago
  The ISA you describe doesn't require aliasing rules. It merely gives you an incentive to have them. C and other languages need much better control over aliasing than the 'restrict' keyword and compiler command-line switches.