vapats

A problem, indeed. I work with embedded MCUs, and can say that the C compilers are rather hideous abattoirs of non-standard __intrinsics__, #pragmas, and asm() statements — not pretty.

When I was a younger man, I made the mistake of trying to anticipate all use-cases and implement The Kitchen Sink right off the bat… Now I’m a bit wiser, and only implement functionality that is actually needed by real-world programs.

At some point, Mill silicon (whether FPGA or not) will be self-hosting its own compiler, so I’d expect that strcmp() and its ilk will be obvious examples of use-cases that demand some attention…

Nice to see another talk, thanks! I particularly liked when you touched on the spiller/filler operation — which suggests a topic for the next talk: some details re Mill context-switching; interrupt handling, thread management, OS kernel calls, etc.

Speaking of which, how do you envision handling real-world I/O? Task (and tax) a Gold Mill as a monoprocessor, or have (say) a few satellite Tins and DMA engines keeping the Gold fed and happy? Given the Mill’s modest transistor budget, it seems that a message-passing multicore approach is not unreasonable…

Give ’em hell, lads! 🙂

Thanks again for another great presentation. The brief recap was nice, and the extended explanations of Mill nuances was even better.

I also very much appreciated the discussion of your business strategy on the Hackaday “Mill CPU for Humans” thread on YouTube, particularly Part 4:

I mostly program in Forth — and the FIFO Belt is as far away from a LIFO stack as you can get — but I see what you folks have achieved here — bravo, and well done!

Dave’s Device makes complete and perfect sense to me.

cheers, – vic

Thanks again for another enjoyable presentation.

Am I correct in thinking that there is a deep relationship in the design of your simulator, and the “specializer” adaptive loader?

(this is pretty much a yes-or-no question; so don’t bother to spend too much time on an elaborate reply).

cheers, – vic

Wow. Simply. Brilliant. I see why you folks are busy securing your patents!

Y’all must have been letting some of these ideas stew for the past several decades…

cheers, – vic

LMAO, yeah right, saddle the poor beast with feature-creep, before it even finishes getting out of the gate, LOL… 🙂

oops, that may have sounded snotty; I was intending to share the laugh with everyone!

• This reply was modified 9 years, 4 months ago by  vapats.

I get it, Sym; you mean having pseudo-ops, that are treated by the specializer the same way as (say) a flop would be replaced by emulation code on a Mill that has no FPU, right?

@carvac; isn’t a blurring job better suited to a GPU?

cheers, – vic

@larryp; yeah, an explicit “retire” seems like an another complication at first… Until you think about it. Kinda reminds me of the branch-delay slot in MIPS and DSPs, which need not be wasteful flushes.

cheers, – vic

Understood, thanks. I missed that step in the toolchain somehow…
🙂