Specification

Mixed-core-architecture chips are common in embedded and other special applications – think the Sony Cell. Usually the cores have dedicated functions – for example, one drives your friendly local nuke plant, and one drive the UI, so process migration is not an issue. The cores need not even be from the same vendor nor be of related architectures. Crimson is a testbed for such use in our specification system.

Process migration across dissimilar cores has been the subject of some academic work. It appears to be practical in a JIT environment, although utility, except for reliability reasons, is questionable.

Our assembler is primarily intended for hardware verification; it is not intended for application use. Manual asm on a Mill is extremely inhumane due to the difficulty of keeping track of belt contents manually; it’s not too hard to read but impractical to write.

Compiler output, which is also specializer input, is a non-textual graph structure. The specializer turns that into target binary, and you can inspect it or get listings in asm text, and even assemble it if you want, but the normal build cycle does not use an asm stage.

In this and all other topics, please do not speculate or suggest ideas in the public forum. We have put and are putting a great deal of work into the Mill, and would like to see some tangible reward for our work. We may already have worked out something in great detail and are just about to file the patents on it, only to have an innocent well-intentioned suggestion give enough of the idea that a patent is no longer available, or could be attacked even if granted.

We do ask for help, but that doesn’t mean that we are looking for postings of ideas, it means that we are looking for real human beings, with expertise – or just thought-out ideas – in the subject, who will join our team, sign the necessary NDA and IP agreements to protect our and their work, and put significant time into the effort on a sweat-equity basis. Contact me directly (ivan@millcomputing.com) if that’s you.

So please, keep the discussion here only on material that has been part of our public disclosures, or material that has already been published by third parties. The latter is especially useful – a cite to an obscure decades-old paper may save us the cost of a pointless patent filing. Or ask questions about how XYZ from a talk works (but don’t suggest alternatives). Or talk about marketing or business matters – Mill Computing has a real technology, not just a business plan and an MBA as so many startups do, so we have nothing we need to protect about the business.

But please, nothing about anything that might be a patent someday; speculations and ideas can hurt us and don’t help you.

Ivan

So just for extreme clarity: The simulator examples given here, and the assembly language shown, is only ever for member-specific code, and never for abstract family code? JITs would generate a LLVM-ish intermediate serialized representation?

The notation used in assembler is common across all members. What you can say in that notation is member specific. Thus addu(b3, b6), addu(b4, 3); is syntactically valid on all members, but only will produce binary on members with two or more adders. JITS (we expect) will produce specializer input notation, or rather a binary form of that, and the same library that the specializer itself uses will turn the JIT code into target binary.

(Related to JITs, but slightly off-topic, but I don’t recall which talk covered it: With the way EBBs and function semantics work, is it possible for a subroutine to have multiple entry points? Just considering optimization possibilities for always-vararg languages.)

It is possible for a function to have multiple entry points, but each entry point must be the entry point of an EBB. All transfers must be to the head (i.e. middle) of an EBB.

When bin-filling the binary instruction encoding, does your software take into account expected popularity of instructions to prefer common instructions for tighter encoding and uncommon instructions as an otherwise needlessly larger encoding to make room for the common ones?

Not really. What you describe is a simplified Gray coding, and we don’t use frequency in determining the encoding of the ops proper. We just determine the natural minimal encoding of each op, and pack for minimal total length. If there’s one op with so many arguments or information to represent that it takes several bits more than any other op then the algorithm will likely use half of the overall entropy just on that one op, and it will encode as the natural length plus one bit to distinguish between that one and all the rest. And so on, for minimal total length.

That said, there are cases in the encoding in which we are in effect encoding by frequency. For example, excess entropy in the exu block (the computational 2-in-on-out ops like ADD) is soaked up by immediate forms, such as add immediate and equal immediate. The range of immediate values supported in any given slot is determined by how much entropy is left over; we add immediate values until we almost but don’t actually go over a bit boundary. The added supported values are small integers, in order, so one slot may support an add-immediate with values 1-17 and the next slot with values 1-243, depending on the rest of the encoding.

This algorithm is in a sense a Gray code, because immediate value usage in actual programs drops in frequency with increasing value – add(3) is more common than add(27). So the algorithm is choosing more frequent operations to encode specially, even though the encoded bit length in any given slot is fixed.

There are other places where the encoding is frequency-sensitive, but in all of them the situation is like with the immediates: we don’t pack single operations by frequency, but we do pack multi-operation sequences by frequency. If there is not an immediate form with the right immediate value, then an expression such as X+243 must be scheduled and encoded as two ops, an con to get the constant on the belt, and then the add. Doing it in one op has better entropy, and also improves schedule latency and slot and belt pressure, so there really is frequency consideration in the algorithm, just not in the encoding of single ops.

Do you anticipate any temporal quantization or aliasing problems with tracking time as (presumably) integer picoseconds in simulation for systems with multiple clock rates? It seems like there could be edge cases where sim would consider activities simultaneous which would be ordered in hardware, depending on the usefulness of that distinction at the sub-picosecond scale.

The sim models multiple clock domains, multiple clock sources (the xtal component), and multiple clock converters (the PLL component). It allows for the cost of the handshaking required to cross domain boundaries.

The sim does not model skewed clock strategies such as appeared in the P4 and some other barn-burner chips. It could, but the hardware guys are not expecting to use such techniques any time soon, and so we wouldn’t know what to specify.

Also, as a Lisp programmer and heavy DSL creator, I must say that when you were showing C++ metaprogramming and especially the enum issue, I could only think of Greenspun’s Tenth Rule. 😉

Had to go look that one up.

The counter-argument embeds Greenspun’s Seventh Rule.

A final reply: as you can see, it’s much easier to reply if you split your posting on the Forum into multiple postings with one topic each 🙂

The Mill already defines signed division, but not in the sense you mean. DIVU accepts unsigned arguments and so the ambiguity for signed does not exist. DIVS accepts signed arguments and produces the C-language result, as is standard in the programming languages that the hardware must accept. We expect that division will be an emulated op (rather than hardware native) on nearly all Mill members. We define a reciprocal-approximation helper op to get the emulation started, and the helper will be native. In practice, the helper and software Newton/Rapheson of the emulation is nearly as fast as a hardware version would be.

It is easy to specify another operation, but it still must be implemented, tested, verified, and documented, and that is not without cost. Consequently we only add ops when their use can improve performance of widely used languages, or where they are needed by critical applications that will access them through intrinsics.

So far we know of no language or app that would justify another division. It is quite rare for an app to have division as a performance-critical step, but if you are aware of any then please bring them to our attention.