Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • nachokb
    Participant
    Post count: 10

    Those characterizations have one thing going for them: there’s no Mill (yet); it doesn’t run any software (yet); OSs haven’t been ported to it (yet).

    So, skepticism is healthy.

    But I think they go too far in dismissing these ideas.

    My favorite: “Lack of object code compatibility between different family members implies a more embedded universe for the product, where the application is known ahead of time and doesn’t change much”. Android proved that’s not the case 10 years ago.

    In particular, the point you are quoting puzzles me. I’m not an expert in CPU design and _I can think of at least 2 ways it absolutely rocks_ (maybe I’m a sucker for immutability): instruction coding entropy and reducing the capacitive load (IIRC, there’s no big crossbar for 500+ registers).

    The part about SAS comes up time and again. The Mill guys _did_ explicitly described mechanisms to deal with fork, relocatable code, etc. They simply ignore all that. Maybe they missed it, which proves my point: everyone has such a strong opinion while _at the same time_ admitting _hey, I may be missing something_.

    It _is_ risky, of course. Let them fail. It’s not you, after all.

  • nachokb
    Participant
    Post count: 10
  • nachokb
    Participant
    Post count: 10

    If I remember correctly from one of the talks, every math op had 4 versions:

    1. saturating: 250 + 30 = 255 (8 bits);
    1. excepting: 250 + 30 = 💣;
    1. wrap-around: 250 + 30 = 24;
    1. expanding: 250 + 30 = 280 (16×8 bits => 2×8×8 bits);

    I believe arbitrary-precision math can be easily implemented using the excepting versions (just handle the special case in an interrupt).

    — nachokb

  • nachokb
    Participant
    Post count: 10
    in reply to: LLVM pointers #2781

    Funny: I thought C would be one of the offenders. After all, basic C syntax exposes pointer arithmetic without any checks (I imagine there *is* a lot of C code out there doing nasty stuff to pointers).

  • nachokb
    Participant
    Post count: 10

    Speaking of which, how does the Mill cope with changing the clock frequency? Having different components running asynchronously sounds like bad news for overclockers.

    Awesome work!

    — nachokb

    [EDIT: grammar]

    • This reply was modified 7 years, 3 months ago by  nachokb.
  • nachokb
    Participant
    Post count: 10
    in reply to: Rust #2196

    No worries. Thanks!

    P.S. Here’s hoping there’ll be some new talk soon…

  • nachokb
    Participant
    Post count: 10

    a supercollider-management op

    Well, now I can’t wait for a supercollider-managing Mill…

    There’s enough flexibility within the Mill architecture to permit a lot of tuning without having to depart incompatibly

    Cool! That was exactly what I hoped.

Viewing 7 posts - 1 through 7 (of 7 total)