Tweet flexes about upgrading to x86, misunderstands x64 naming joke

i stands for imaginary unit

Already using 128-bit pointers...

1. @

   ▾ @qtsmolcat · 1y 7 replies ▸

   I use 512 bit vectors where u at

   Report

   1. @

      ▾ @SamsonovAnton · 1y 6 replies ▸

      SIMD operations, regardless of their register width (which may easily be as large as 4096 bits these days), are used to process the very same 8 to 64-bit pieces of data as general-purpose scalar registers do. I was referring to pointers, which are handled by scalar registers and traditionally limited to 16, 32 and currently 64 bits, thus being able to address 64 kilobytes, 4 gigabytes and 16 exabytes of [virtual] memory. In some processor architectures, those pointers may be extended to descriptors that store extra metadata needed to protect memory access from programmatic errors and vulnerabilities; for example, if regular pointer occupies 64 bits, the corresponding descriptor may have 128 bits. That metadata can be handled by conventional 64-bit registers, but it is obviously faster when a hardware acceleration is implemented for this purpose — to minimize overhead the very same way as SIMD does for processing bulk data.

      Report

      1. @

         ▾ @azizhakberdiev · 1y 5 replies ▸

         This thing really exists? It sounds obsolete because operating systems already do it on a program level. If it really does improve performance then it has to become a new standard

         Report

         1. @

            ▾ @andrei_nik_kolesnikov · 1y 1 reply ▸

            pac/bti on arm exists for a while already, but it is not about perf, its about preventing ROPs

            Report

            1. @

               @andrei_nik_kolesnikov · 1y

               program level does nothing as it is always way too easy to smash the stack even by one improperly handled byte

               Report
         2. @

            ▾ @SamsonovAnton · 1y 1 reply ▸

            Regular memory protection (that one at the OS level) concerns page access — that is 4096-byte granularity at most, not to mention huge pages of 2 megabytes or more — at process, so that other programs / users cannot use memory that is not their. I was referring to memory protection that has byte or word granularity (for example, 1-byte granularity for object boundaries and 4-byte granularity for uninitialized values) that protects the program against itself — such as off-by-one index errors. It's not about performance — it's about security and debugging, because the program is trapped instantly the very moment it attempts incorrect action, rather than when the memory is corrupted so badly that it is nearly impossible to trace back to the root cause. When paired with memory tagging (e. g. "this word contains uninitialuzed data / numeric data / function address / memory descriptir") and implemented in CPU hardware, it provides bulletproif protection against most common programmatic errors, that the program itself cannot bypass, as descriptors and tags cannot be forged programmatically like regular pointers. it has to become the new standard It's not that simple, though. • The whole program must run in this mode, including all the libraries. • Many optimization tricks violate the strict access rules — for example, fast implementations of strlen() that analyze multiple bytes at once. • While some protections have near zero performance penalty, others may be expensive — for example, use-after-free protection against "zombie" references. • Each 128-bit descriptor uses twice as much memory than a regular 64-bit pointer, which exhausts L1 and L2 caches twice as fast. • There are tons of poorly written programs that store pointers in generic integer variables, falsely assuming that it is always possible to convert an integer number back to a pointer — that is not possible with descriptors, as type casting removes their tag that cannot be forged back later. • There are tons of poorly written programs that falsely assume that pointer size is the same as a corresponding integer number size — that is obviously not true for descriptors that store extra metadata beyond that of a pointer visible to application. As a consequence, most software that we use today and that would benefit the most from such kind of protection, can hardly be ported to secure mode, — bur rather the most critical programs with clean code, those that are worth huge efforts.

            Report

            1. @

               @azizhakberdiev · 1y

               Thanks for clarification. I didn't know it is a separate layer of protection than OS level. I was a little bit puzzled when seeing discussions about large register size advantages when "larger means slower" in computer architecture. I thought that if this allows to transfer burdens of OS to CPU then it would rather pay off, but surely it is not that straightforward

               Report
         3. @

            @CcxCZ · 1y

            https://www.arm.com/architecture/cpu/morello https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

            Report

8086 is the future

Have you heard 'bout transistors? They say they are hot stuff

nah 64-bit access is already too wide

1. @

   @TheFloofyFloof · 1y

   That's what big 64 wants you to believe

   Report

nah nintendo64 is awesome

1. @

   @RiedleroD · 1y

   that's a MIPS-based architecture, mostly 32-bit with 64-bit characteristics

   Report

x87 exists, but he's still on x86...

In My college they are using 88💀

68k anyone?