4 ms·

"Intel loves complexity" Intel loves performance, because people want performance. Complexity is the cost of increased performance. As an example, I would gues

by andars 10y ago

"Intel loves complexity" Intel loves performance, because people want performance. Complexity is the cost of increased performance. As an example, I would guess that of the ~2000 pages of the instruction set reference, at a minimum 1000 pages document the various SIMD instructions. You don't need those, or the floating point operations, or SHA instructions, but I don't see any harm done by making them available.

kazinator 10y ago
1000 pages comes close to ANSI Common Lisp [1994], which is still criticized by some bitter old Lisp trolls for its size. It's just some CPU instructions! Maybe they aren't doing a good job of describing them succinctly?
- andars 10y ago
  They probably aren't describing them very succinctly, because there isn't really a benefit to dropping information in the complete instruction set reference. If you don't want all of the information, look at the instruction set summary instead (~40 pages in volume 1). These things aren't written to be brief, they are written to be complete.
flamedoge 10y ago
don't you technically just need mov which is said to be turing complete?
- fnj 10y ago
  It's not clear to me how [simple unconditional] mov could possibly do the job alone. I believe it could only work if it incorporates "magic" memory locations - e.g., storing at location x executes math combining location x and location y in some way and alters location z. This simply begs the question by moving logic behind the curtain. I think the single instruction which can do the entire job without any magic assist is subneg x, y, z: Subtract location x from location y; store the result in location y; and branch to location z if result is less than 0; else proceed to next. Or various trivial variations of the same idea. Any complication beyond this is no more than syntactical sugar and performance optimization.
  - pjc50 10y ago
    See https://github.com/xoreaxeaxeax/movfuscator https://github.com/xoreaxeaxeax/movfuscator
    - fnj 10y ago
      Once I checked out the reference at the end of README.md, I like it. I could try to object that the "magic" has been moved into the addressing modes of the mov, but that would be a bit arbitrary. If you focus only on direct memory addressing (no indirect or indexed), mine does still work, but mov doesn't. I think.

by andars 10y ago

kazinator 10y ago

1000 pages comes close to ANSI Common Lisp [1994], which is still criticized by some bitter old Lisp trolls for its size. It's just some CPU instructions! Maybe they aren't doing a good job of describing them succinctly?

andars 10y ago
They probably aren't describing them very succinctly, because there isn't really a benefit to dropping information in the complete instruction set reference. If you don't want all of the information, look at the instruction set summary instead (~40 pages in volume 1). These things aren't written to be brief, they are written to be complete.

flamedoge 10y ago

don't you technically just need mov which is said to be turing complete?

fnj 10y ago
It's not clear to me how [simple unconditional] mov could possibly do the job alone. I believe it could only work if it incorporates "magic" memory locations - e.g., storing at location x executes math combining location x and location y in some way and alters location z. This simply begs the question by moving logic behind the curtain. I think the single instruction which can do the entire job without any magic assist is subneg x, y, z: Subtract location x from location y; store the result in location y; and branch to location z if result is less than 0; else proceed to next. Or various trivial variations of the same idea. Any complication beyond this is no more than syntactical sugar and performance optimization.
- pjc50 10y ago
  See https://github.com/xoreaxeaxeax/movfuscator https://github.com/xoreaxeaxeax/movfuscator
  - fnj 10y ago
    Once I checked out the reference at the end of README.md, I like it. I could try to object that the "magic" has been moved into the addressing modes of the mov, but that would be a bit arbitrary. If you focus only on direct memory addressing (no indirect or indexed), mine does still work, but mov doesn't. I think.