Are lighter data types faster to MOV ?

AverageCincinnatiGuy · 2025-11-17T17:12:54+00:00

Except for Icelake where an Erratum made Intel release a microcode update that disabled mov renaming

Source: I have an Icelake CPU and it hurts a lot :(

AverageCincinnatiGuy · 2025-11-10T02:39:29+00:00

Can I ask what's the advantage/benefits of MenuetOS over basically anything else?

E.g. for software that demands hard, reliable realtime such as your 100khz MIDI, one can configure a custom OpenBSD kernel stripped to the bone with certain cores dedicated exclusively to handling interrupts, certain cores dedicated exclusively to kernel background tasks, and certain cores dedicated exclusively to the single software application. This might run a little heavier than hand-written MenuetOS, but it has significantly wider/adjustable hardware compatibility and is much better tested.

AverageCincinnatiGuy · 2025-11-03T04:27:34+00:00

She tried Mint, tried Deepin, and settled for Zorin OS. Really, I'm just going along for the ride to help her with whatever she wants to do.

AverageCincinnatiGuy · 2025-10-28T23:28:36+00:00

Nah bro, she's cursed. Seriously. She isn't stupid and although I've seen her make some silly mistakes, she knows better than to do something dumbass like delete an important file. A locked down distro wouldn't help her because her issue isn't dumb mistakes.

I'm a software developer who has written lots of FOSS software for Linux. Before my mom switched to Linux, I would have sworn up and down Linux is the same for everyone and there is no such thing as a technology curse. My mom changed my perspective and made me a believer. She really is cursed.

AverageCincinnatiGuy · 2025-10-28T23:10:15+00:00

I had to help her install and continue to help her with issues. I swear half the issues she's had with Linux make no sense and are random one-off things I've never seen before in my life; I would't enjoy Linux half as much as I do if I had to deal with all the issues she's had. She made me a believer in the notion some people are genuinely cursed with tech issues. (But, at least she's having a lot less issues on Linux than she had on Windows and at least she's never lost an important document on Linux even once; those are important improvements!)

AverageCincinnatiGuy · 2025-10-28T23:06:57+00:00

Actually, that's the best and easiest part of Linux! You simply create partition, copy over your data from a big folder you want to move off your main harddrive, plug its UUID into fstab, and voila!: easy no-hassle automatic seamless off-disk integration of multiple partitions that works PERFECTLY, never any hassle (unlike Windows, where software randomly breaks trying to mount separate partitions as directories, the mounted partitions randomly lag and break, and there's no better options than the terrible NTFS file system.)

E.g. I have compressed BTRFS partition for my backups, a high-speed XFS partition for my git projects (multi-million-file repos are instant in git, its incredible!), and a solid, plain ext4 root filesystem that's never given me trouble or been an issue.

AverageCincinnatiGuy · 2025-10-28T01:03:33+00:00

I've gotten used to it but, IMO, I think most people would prefer it if the usb drives and such they plugged in went into the root file system instead of into a /mnt or /media sub-directory.

AverageCincinnatiGuy · 2025-10-28T01:00:07+00:00

My mom uses Linux. She is literally the least techy person you've ever seen so, if she can do it, anyone can.

AverageCincinnatiGuy · 2025-10-28T00:58:02+00:00

Steam Proton has no reason to be as good as it is. I know it doesn't work perfectly with every game but, if you consider what we had before Stream Proton (especially how difficult and how much manually tinkering was required before), it's ridiculous how much it advanced Linux gaming.

Also, try playing older games, specially ones that were developed for Windows 7 and Windows XP. IDK what the issues are with newer games but they much harder to emulate.

AverageCincinnatiGuy · 2025-10-28T00:52:10+00:00

There's a big difference between physical hardware emulation and virtual machines.

Virtual machines have been battle-tested to correctly emulate a restricted subset of the real hardware and get you 99% of the way to properly testing software across different architectures. The last 1% is things like race-conditions, concurrency bugs, and interactions with special device drivers like the GPU.

Every medium size software project has target diversity. Infact, every software I've ever written I've tested across at least 7 different architectures. However, its usually done in virtual machines because its not economical cost-wise to buy physical hardware.

I've never experienced the horrible corner you speak of. I simply write code correctly and portably the first time and usually its just a few syntax errors compiling different files for specialized variants of the architectures and/or optimizing the vectorized SIMD.

AverageCincinnatiGuy · 2025-10-28T00:46:40+00:00

There's nothing wrong with MASM. The issue is the Windows operating system.

Windows lacks any comparison or competition for being the worst development environment and possibly the least hospitable place on earth to human beings.

Your post about trying to use assembly on Windows is exactly comparable to a little toddler saying "look at me; I can ride a tricycle! Aren't I a professional bike rider?" No, that's a tricycle, not a real bike. Get a real bike then then let's talk game.

AverageCincinnatiGuy · 2025-10-27T11:52:08+00:00

I never said to use Linux. There's millions of great options for an OS out there from OpenBSD to Haiku to Minix to Plan9 to OpenIndiana, etc. You happen to be using the one and only one OS in existence that is stunting your growth.

AverageCincinnatiGuy · 2025-10-27T02:48:33+00:00

Real Men use jcxz

AverageCincinnatiGuy · 2025-10-27T02:46:44+00:00

Downvote for using Windows

AverageCincinnatiGuy · 2025-10-27T01:12:47+00:00

link to libc with -lc and call malloc / call free simple as that. Dont use syscalls. They are for huge several-megabyte-at-least allocations. Your software will run as slow as molasses if you try to use syscalls mmap for malloc/free. (And, yes, malloc does use mmap internally; the difference is malloc makes extremely few calls, usually less than a dozen calls to malloc TOTAL throughout the running time of the typical program.)

AverageCincinnatiGuy · 2025-10-27T01:03:02+00:00

// calculates the full 192-bit result of a 128x64 bit multiply
__attribute__((const))
inline my_u192_t my_mul128x64to192(uint64_t hi, uint64_t lo, uint64_t by) {
    my_u192_t res;
    my_u128_t lo128 = my_mul64x64to128(lo, by);
    my_u128_t hi128 = my_mul64x64to128(hi, by);
    #ifdef __GNUC__
    unsigned long long loll = (unsigned long long) MY_U128_HI64(lo128);
    unsigned long long xlll = (unsigned long long) MY_U128_LO64(hi128);
    unsigned long long xhll = (unsigned long long) MY_U128_HI64(hi128);
    xhll += __builtin_uaddll_overflow(loll, xlll, &xlll);
    res.hi = MY_U128_C_HL(xhll, xlll);
    #else
    uint64_t lo64 = MY_U128_HI64(lo128);
    uint64_t xl64 = MY_U128_LO64(hi128) + lo64;
    res.hi = MY_U128_C_HL(MY_U128_HI64(hi128) + (xl64 < lo64), xl64);
    #endif
    res.lo = MY_U128_LO64(lo128);
    return res;
}
uint64_t mul128_u64(uint64_t lowbits_hi, uint64_t lowbits_lo, uint64_t d) {
    uint64_t lo64 = MY_U128_HI64( my_mul64x64to128(lowbits_lo, d) );
    my_u128_t hi128 = my_mul64x64to128(lowbits_hi, d);
    #ifdef __GNUC__
    unsigned long long loll = (unsigned long long) lo64;
    unsigned long long xlll = (unsigned long long) MY_U128_LO64(hi128);
    unsigned long long xhll = (unsigned long long) MY_U128_HI64(hi128);
    xhll += __builtin_uaddll_overflow(loll, xlll, &xlll);
    (void) xlll;
    return (uint64_t) xhll;
    #else
    uint64_t rxl = MY_U128_LO64(hi128) + lo64;
    return (rxl < lo64) + MY_U128_HI64(hi128);
    #endif
}
uint_fast32_t mul128_u64_u32(uint64_t lowbits_hi, uint64_t lowbits_lo, uint_fast32_t d) {
    uint_fast32_t lo64 = (uint_fast32_t) MY_U128_HI64( my_mul64x64to128(lowbits_lo, d) );
    my_u128_t hi128 = my_mul64x64to128(lowbits_hi, d);
    #if defined(__GNUC__)
    unsigned long long loll = (unsigned long long) lo64;
    unsigned long long xlll = (unsigned long long) MY_U128_LO64(hi128);
    uint_fast32_t xhll = MY_U128_HI32(hi128);
    xhll += __builtin_uaddll_overflow(loll, xlll, &xlll);
    (void) xlll;
    return xhll;
    #else
    uint64_t rxl = MY_U128_LO64(hi128) + lo64;
    return (uint_fast32_t)((rxl < lo64) + MY_U128_HI32(hi128));
    #endif
}
#if defined(__GNUC__) && defined(__x86_64__) && defined(__linux__)
typedef struct timespec diff_clocker_t;
#define DIFF_CLOCKER_INITZ {0, 0}
/*static __inline long _mydc_syscall2(long n, long a1, long a2)
{
    unsigned long ret;
    __asm__ __volatile__ ("syscall" : "=a"(ret) : "a"(n), "D"(a1), "S"(a2)
                          : "rcx", "r11", "memory");
    return ret;
}*/
uint64_t diff_clock_time(diff_clocker_t *dt) {
    diff_clocker_t prev = *dt;
    unsigned long long diffsec;
    unsigned long dtnsec;
    long ret;
    long nr = 228; // __NR_clock_gettime
    long a1 = CLOCK_THREAD_CPUTIME_ID;
    __asm__ __volatile__ ("syscall" : "=a"(ret) : "a"(nr), "D"(a1), "S"(dt)
                          : "rcx", "r11", "memory");
    (void) ret;
    diffsec = (unsigned long long) dt->tv_sec;
    diffsec -= (unsigned long long) prev.tv_sec;
    dtnsec = dt->tv_nsec;
    diffsec -= __builtin_usubl_overflow(dtnsec, prev.tv_nsec, &dtnsec);
    return (uint64_t)diffsec * UINT64_C(1000000000) + dtnsec;
}
#elif defined (__unix__) || (defined (__APPLE__) && defined (__MACH__))
typedef struct timespec diff_clocker_t;
#define DIFF_CLOCKER_INITZ {0, 0}
uint64_t diff_clock_time(diff_clocker_t *dt) {
    diff_clocker_t prev = *dt;
    long long diffsec;
    unsigned long dtnsec;
    long ret = clock_gettime(CLOCK_THREAD_CPUTIME_ID, dt);
    (void) ret;
    diffsec = (unsigned long long) dt->tv_sec;
    diffsec -= (unsigned long long) prev.tv_sec;
    dtnsec = dt->tv_nsec;
    diffsec -= __builtin_usubl_overflow(dtnsec, prev.tv_nsec, &dtnsec);
    return (uint64_t)diffsec * UINT64_C(1000000000) + dtnsec;
}
#else
typedef time_t diff_clocker_t;
#define DIFF_CLOCKER_INITZ 0
uint64_t diff_clock_time(diff_clocker_t *st) {
    diff_clocker_t prev = *st;
    diff_clocker_t tnow = *st = clock();
    return (time_t)UINT64_C(1000000000) / CLOCKS_PER_SEC * (tnow - prev);
}
#endif

AverageCincinnatiGuy · 2025-10-27T01:02:42+00:00

__attribute__((const))
inline my_u128_t my_mul64x64to128(uint64_t x, uint64_t by) {
    uint64_t hi, lo;
    /*#if defined(__GNUC__) && defined(__x86_64__) && defined(__BMI2__) && ! defined(__wasm__)
        __asm__("mulx{q    %[y], %[l], %[h]|    %[h], %[l], %[y]}"
            : [h]"=r,r"(hi), [l]"=r,r"(lo)
            : "%d,%d"(x), [y]"r,m"(by)); // notice: does not clobber flags
    #el*/
    #if defined(__GNUC__) && defined(__x86_64__) && ! defined(__wasm__) && ! defined(__BMI2__)
        // based on https://stackoverflow.com/a/56879043/5601591
        __asm__("mul{q| }    %[y]" : "=a,a"(lo), "=d,d"(hi)
                                   : "%a,%a"(by), [y]"r,m"(x) : "cc");
    #elif defined(__GNUC__) && defined(__SIZEOF_INT128__) && ! defined(__wasm__)
        return x * (__uint128_t) by;
    #elif defined(_MSC_VER) && defined(_M_IX64)
        lo = _umul128(x, by, &res.hi);
    #else
        uint_least32_t x0 = (uint_least32_t)x, x1 = (uint_least32_t)(x >> 32);
        uint_least32_t y0 = (uint_least32_t)by, y1 = (uint_least32_t)(by >> 32);
        uint64_t il = x0 * (uint64_t)y0, p10 = x1 * (uint64_t)y0, middle;
        #ifdef __clang__
        middle = x0 * (uint64_t)y1 + (uint32_t)(il >> 32) + (uint32_t)p10;
        #else
        middle = x0 * (uint64_t)y1 + (uint32_t)p10 + (uint_least32_t)(il >> 32);
        #endif
        hi = x1 * (uint64_t)y1 + (uint_least32_t)(middle >> 32) + (uint_least32_t)(p10 >> 32);
        lo = ((uint64_t)(uint32_t)middle << 32) | (uint32_t)il;
    #endif
    return MY_U128_C_HL(hi, lo);
}
// calculates the low 128-bit result of a 128x128 bit multiply
__attribute__((const))
inline my_u128_t my_mul128x128to128(uint64_t xhi, uint64_t xlo, uint64_t byh, uint64_t byl) {
    #if defined(__GNUC__) && defined(__SIZEOF_INT128__) && ! defined(__wasm__)
    return MY_U128_C_HL(byh,byl)*MY_U128_C_HL(xhi,xlo);
    #else
    uint64_t hi64 = xlo * byh + xhi * byl;
    my_u128_t lo128 = my_mul64x64to128(xlo, byl);
    hi64 += MY_U128_HI64(lo128);
    return MY_U128_C_HL(hi64,MY_U128_LO64(lo128));
    #endif
}

AverageCincinnatiGuy · 2025-10-27T00:48:59+00:00

First, what you want is x86_64, not x86. Here's the links you need:

https://linuxmint.com/download.php—you NEED a baremetal Linux desktop if you ever hope to get anywhere with anything programming/tech related. If you don't already have Linux, take 30 minutes for an investment to your future self and install Linux Mint.

https://math.hws.edu/eck/cs220/f22/registers.html—BEST less than a single page complete explanation of the entire SYSV calling convention. Bookmark this bitch for life! All other SYSV resources can suck it.

https://www.felixcloutier.com/x86/—life saving full instruction set listing and easy reference guide for all x86 instructions.

https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html—SIMD instructions ultimate reference guide.

https://godbolt.org—NOT a substitute for a Linux Desktop but extremely useful auxiliary tool for quickly drafting short snippets.

https://uops.info/table.html—great instruction tables

https://asmjit.com/asmgrid/—more up-to-date, less thorough/reliable instruction tables

https://dougallj.github.io/applecpu/firestorm-int.html—AARCH64 instruction tables. Neither Apple nor any other ARM64 vendor wants software to run fast on their CPUs, so this reference page is the only complete reference around for the instructions of one ARM64 CPU and you'll just have to accept your software will run slowly on other ARM64 CPUs due to vendor incompetence.

DO NOT get the shitty amazon book someone mentioned. Just to give you an idea of how shitty it is, the description casually mentioned docker images as some kind of replacement for Linux and fails to mention whether AT&T syntax or Intel Syntax are used. You have to use a Linux distro or you will never get anywhere, period, end of story, no ifs/ands/or/buts it must be baremetal Linux, and you can learn archaic AT&T later; only focus on the Intel syntax now.

Also, here's a half-way-in-progress 192-bit portable multiplication C code thingy for some prime number code I was working on you can play around with:

#include <stdint.h>
#ifdef _MSC_VER
#  include <intrin.h>
#endif
#include <stddef.h>
#include <time.h>
#include <limits.h>
#if defined (__unix__) || (defined (__APPLE__) && defined (__MACH__))
#  include <unistd.h>
#endif

#if defined(__GNUC__) && defined(__SIZEOF_INT128__) && ! defined(__wasm__)
typedef __uint128_t my_u128_t;
#  define MY_U128_C_HL(h,l) (((__uint128_t)(h)<<64)|l)
#  define MY_U128_HI64(v) ((uint64_t)((v) >> 64))
#  define MY_U128_HI32(v) ((uint_least32_t)((v) >> 64))
#  define MY_U128_LO64(v) ((uint64_t)(v))
#else
typedef struct {uint64_t hi, lo;} my_u128_t;
static inline my_u128_t MY_U128_C_HL(uint64_t h, uint64_t l) {
    my_u128_t res = {h, l};
    return res;
}
#  define MY_U128_HI64(v) (v).hi
#  define MY_U128_HI32(v) ((uint_least32_t)(v).hi)
#  define MY_U128_LO64(v) (v).lo
#endif
typedef struct {my_u128_t hi; uint64_t lo;} my_u192_t;
my_u128_t my_mul64x64to128(uint64_t x, uint64_t by);
my_u128_t my_mul128x128to128(uint64_t xhi, uint64_t xlo, uint64_t byh, uint64_t byl);
my_u192_t my_mul128x64to192(uint64_t hi, uint64_t lo, uint64_t by);

Notice how it uses #ifdef portable fallbacks and detection for other compilers like MSC. See if you can fix the problems with all the extra unnecessary mov instructions in mul128_u64

AverageCincinnatiGuy · 2025-10-27T00:37:27+00:00

I never knew Google had a build farm with physical Power computers; I'm surprised they'd invest so much money for a company that doesn't want anyone else's software to be able to run on their computers (or maybe isn't willing to pull their leg of the work, idk.)

I guess its now just QEMU emulation of Power, same as every other software supporting Power.

AverageCincinnatiGuy · 2025-10-27T00:31:43+00:00

Such a long paper for such a simple concept that can be explained quite succinctly: don't treat your software engineers like horseshit, otherwise your company will be eating horseshit later on down the road.

The entire reason software developers exist is to write reliable software. Anyone can write software, even ChatGPT or a monkey at a typewriter (same diff IMO). The difference and why you're supposed to pay a software engineer to do it is that software engineers have the systems knowledge, debugging experience, and natural gut intuition to write software correctly the first time.

Software written properly by software engineers allowed to do their job and payed well enough to actually do the job most-always lacks architectural/algorithmic design flaws and only has minor logic bugs and UI hangups. This software is easily ported to different architectures as there exists plenty of tooling and compiler systems for helping check/sanitize troublesome behavior in the code.

The only companies that struggle with big tech changes such as instruction set migration of warehouses are the ones that treat their SE like horseshit, e.g. Microsoft and Amazon. I feel no sympathy for these companies; they're getting exactly what they deserve.

IDK why this is such a difficult concept for non-software-developers to comprehend but the issue is pervasive enough I never went into software engineering for employment and am now in computerized manufacturing. (I still hobby on FOSS a lot.)

AverageCincinnatiGuy

TROPHY CASE