Will_Edwards

Why yes, its been excitingly busy at the mill recently and we will get to share that and be excitingly busy in public too soon!

We are very very very close to publishing ISA specs and there are more talks scheduled. As usual, subscribe to the mailing list or visit the forums regularly to get details.

Ivan will give a keynote at this year’s Open Source Days in Copenhagen: http://www.opensourcedays.org/2014/ – finally a chance for us Europeans to hear him live.

Hi Laurent,

Thanks for the encouragement!

On the first point, if the OoO can do all 10 loads in parallel then all 10 must be independent. If all 10 are independent then the compiler can statically schedule them in parallel too.

Things actually get interesting if the loads alias stores, as on the Mill the loads snoop/snarf on the stores.

Re patents: it’s best to to hint nothing at all! Please don’t go this route of disowning ideas publically.

The metadata aspect is interesting. Of course Mill SIMD is very familiar to people used to thinking about SIMD on other platforms, but its broader too.

The widening and narrowing ops are very fast and the range of ops that work on vectors is so much wider than other ISAs.

The tracking of error and None NaRs allows vectorization of so much more (see the auto vectorization in the Metadata talk and the Pipelining talk examples, and think how you can use masking in general open code too) so its swings and roundabouts but generally a really big win.

I wasn’t at Hot Chips, although Ivan was, but like many I read about the Nvidia transcoding.

It reminded me strongly of Transmeta.

Because the chip must still run untranslated ARM code at a reasonable speed, it must basically be an OoO superscalar chip, and all the inefficiencies that implies. It must still have the full decode logic etc.

And therefore the microops they cache must be very close to the ARM ops they represent.

This aside, I expect they execute very well. Its a good halfway house and underlines how expensive CISC and even RISC to uop decode is; one imagines x86 chips getting much the same advantage if they store their uop decode caches too.

This recent talk by Rob Pike describes a simple APL variant that would be fun to think about on the Mill; an interpreted language that can use the Mill’s vectorization nicely.

Yes, it means exactly that. This part of the address space is still protected by the normal Mill memory protection mechanism so an operating system can ensure that nobody unwittingly has an actual alias though.

Thank you kindly for finding and sharing with us, Larry 🙂

I’ve sent out polite enquiries to the organisers of the more recent talks and hopefully we’ll track down the other videos soon too.

If anyone spots them before us please do post here!

an upcoming presentation on the abstract Mill, viewed as a virtual machine. If I recall, this was by somebody other than Ivan, possibly not an official Millcomputing person

I think you might mean Terje Mathisen’s talk “Are virtual machines the future?” at NNUG, Oslo, Norway on the 22nd September? Terje is absolutely an official Millcomputing person 🙂 Fortunately the talk was videoed.

Terje did another talk at Trondheim on the 21st October. This one was allegedly videoed too, but we haven’t seen the video yet.

Just last week Ivan gave a talk in Copenhagen, and this too was videoed – I was there and saw the cameras – but again we haven’t yet got our hands on the tapes yet.

Of course everyone is subscribed to the mailing list already right?

On the 21st November 2014 Terje Mathisen will be giving a Mill CPU talk at http://buildstuff.lt/ Vilnius, Lithuania. And on the 10th December I will be giving at talk in Tallinn, Estonia. There’s also likely a talk in December at Microsoft, Seattle provisionally compiler-themed.

So the year isn’t over yet! 😀

Re wiki, glad its being discovered and explored 🙂 Its very much an ongoing project and will grow.

PS Millcomputing folks. Please feel free to delete this post if I’ve mentioned things you’d rather not yet have on the forums. If so, my apologies.

LOL no fear 🙂

• This reply was modified 9 years, 5 months ago by  Will_Edwards. Reason: Updated with link to video

Perceptive. Some concrete Mills may have deferred control flow (e.g. the delay on the br op) and this may need careful simulator profiling for the case of call too.

the actual function that will be called is hoisted all the way up to an input parameter, which again would be an ideal for software injecting “upcoming|next EBB” hints into the prefetcher.

Exactly.

Luckily this hoisting would happen in the specializer (or jit), which can use deferred calls or other hints if the concrete Mill supports it. It is nothing a conventional compiler generating the flow graph need concern itself with.

The IDs are unforgeable not because they are unguessable but because they are managed by hardware.

That’s a perfectly reasonable implementation path for C++.

The compiler will still have to recognise it for what it is in order to know to use the Mill’s saturating opcodes in the emitted binary.

More generally, many uses of saturating arithmetic is in DSP and graphics programs which are often written in C.

Thx for the link. I haven’t read it yet, but do they talk about auto-vectorizing non-vector code? Can they take code that doesn’t have neon or whatever and turn it into vectors and such?