4 ms·

I've explained[0][1] in the past why this is nonsense, and seem to have eventually convinced[2] the one person who actually read the literature. Beyond that--c

• mhh__ 4y ago
• WalterBright 4y ago
  I've worked with languages with multiple fundamental pointer types (needed for 16 bit code). This kind of thing never worked well. For example, you'd need 4 versions of strcpy() to deal with 2 pointer types. What a mess DOS programming was with that.
  • moonchild 4y ago
    It's a good thing that's not the solution I proposed, then.
    • WalterBright 4y ago
      > So instead, generate multiple definitions and rewrite callers:
      • moonchild 4y ago
        Yes, in much the same fashion as with template functions: multiple definitions are generated, and callers are rewritten to target the appropriate specialisation.
        • WalterBright 4y ago
          Code bloat comes with its own performance problems (code caching). Besides, I seriously doubt that there's much gold in unambiguously recognizing stack pointers. I try to put as much as possible on the stack, but it just doesn't seem like much. The more stack allocation you manage to do, the more code bloat gets generated. Any malloc'd pointer will look just like a GC pointer, so you'll be paying the penalty for all of those. How these tradeoffs play out will be difficult to determine in advance. If you've the confidence that it will work out favorably, by all means, give it a try. Of course, one could add user annotations, but annotations are generally disliked.
          • moonchild 4y ago
            > Any malloc'd pointer will look just like a GC pointer, so you'll be paying the penalty for all of those. I don't see why. A small amount of manual tagging for extern(C) things—done in this case as part of the standard library, so opaque to user code—will go a long way in that regard. And in any custom allocator, automatic inference should work just fine, since the data returned will be clearly derived from the already-tagged malloc/mmap/VirtuallAlloc/whatever (type info does still have to be associated manually, of course, as part of the GC.addRange dance, to avoid spurious pinning).
            • WalterBright 4y ago
              That would all come undone with separate compilation. You'd have to recompile the entire program every time. You'd also have to keep around a massive amount of data at compile time. A variable that's a pointer to a struct, can't just be represented as a pointer to a struct. It'd have to have a map of which pointers in the struct are managed for every pointer to that struct. The way the D compiler is implemented now, a struct S has only one instance, as every pointer to a struct's type points to that same instance. And still sometimes people compile programs so large the compiler runs out of memory.
              • moonchild 4y ago
  • zozbot234 4y ago
    > What a mess DOS programming was with that. You could always use huge pointers in the general case, and treat 16-bit pointers as an optimization only. This is probably how these platforms might be best supported by something like modern GCC/LLVM.
    • WalterBright 4y ago
      > You could always use huge pointers in the general case, and treat 16-bit pointers as an optimization only Data flow analysis isn't that good.
      • zozbot234 4y ago
        > Data flow analysis isn't that good. It definitely wasn't in the old DOS days. But it's worth testing the approach in the context of modern platforms.
• Imperatorn 4y ago
  Interesting, I will read through those