RISC wars

By: Maynard Handley (name99.delete@this.name99.org), April 16, 2017 9:45 pm
Room: Moderated Discussions
Brett (ggtgp.delete@this.yahoo.com) on April 16, 2017 7:56 pm wrote:
> Maynard Handley (name99.delete@this.name99.org) on April 16, 2017 5:48 pm wrote:
> > Brett (ggtgp.delete@this.yahoo.com) on April 16, 2017 3:02 pm wrote:
> > > dmcq (dmcq.delete@this.fano.co.uk) on April 16, 2017 4:36 am wrote:
> > > > Brett (ggtgp.delete@this.yahoo.com) on April 15, 2017 4:18 pm wrote:
> > > > > Michael S (already5chosen.delete@this.yahoo.com) on April 15, 2017 1:04 pm wrote:
> > > > > > Brett (ggtgp.delete@this.yahoo.com) on April 15, 2017 12:48 pm wrote:
> > > > > > >
> > > > > > > Yes this architecture looks a lot like the Mill, it's what
> > > > > > > I was working on by myself before Mill was announced.
> > > > > >
> > > > > > Mill is certainly not stack-based. If anything, it is queue-based.
> > > > >
> > > > > I was making the concept easier to understand, letting values fall off the end of a belt is better than
> > > > > resetting the stack every three instructions. (One bit in the push opcode can reset the stack.)
> > > > > Though I wanted to make the micro-threads more visible to the hardware, makes going wider easier.
> > > > >
> > > > > The really nice part of this design is that you can put a ARM64 decoder on the front end in addition
> > > > > to your own decoder. (I did not realize this two years ago.) You would dump ARM32 of course.
> > > > >
> > > > > > > The days of RISC are finally numbered, right when ARM64 has finally won the RISC wars. ;)
> > > > > >
> > > > > > Did ARM64 really win it?
> > > > >
> > > > > Yes, by every metric ARM64 has 99% market share of 64 bit RISC, and near that
> > > > > for 32 bit RISC. (It will take a few years for autos to switch from PowerPC.)
> > > > >
> > > > > > Last time I looked, RISC-V crowd was convinced that the mother of all RISC wars is not started yet.
> > > > >
> > > > > Fools, but they are part of the natural timeline of expensive to near free.
> > > > >
> > > > > > Back to origins of the thread, IMHO, it would be pity if RISC-V wins at the end, because
> > > > > > I think that it is not as good as the most current form of its ancestor.
> > > > >
> > > > > MIPS64, yuck.
> > > > > What is with MicroMIPS having only 16 registers?
> > > > > Two operand like x86 is plenty most of the time and an extension word can add a proper
> > > > > destination register for the cases where you want three operands. Cutting the register
> > > > > count to fit three operands into 16 bit instructions seems stupid to me.
> > > > >
> > > > > MIPS is basically declaring that having 32 registers was a mistake, which may be accurate.
> > > > > Even if 32 registers is a mistake, this makes intermixing
> > > > > MicroMIPS opcodes with MIPS64 opcodes more difficult.
> > > > >
> > > > > This causes image problems that make adoption more difficult. You
> > > > > need a good marketing message to overcome this, which MIPS lacks.
> > > >
> > > > Personally if I was doing a stack machine I'd have the stack in memory. To make it efficient I'd
> > > > have some stack access instructions that didn't check for clashes with indirect accesses and use
> > > > them for automatic variables which didn't have their addresses passed around. Then the data accessed
> > > > that way could be in a separate cache accessed earlier in the pipeline just like registers. It
> > > > might be okay for micros that required fast interrupts and small code size, but one would need
> > > > more instructions in general than RISC and have to stick them together to get efficiency.
> > >
> > > No one sane would design a stack machine today.
> > > I am saying that RISC maps poorly to the underlying hardware at the six wide generation.
> > > Ironically the 8087 stack does map fairly well to the underlying hardware,
> > > or would if those were integer units instead of floating point units.
> > >
> > > Most programmers are no different than users, they do not care what
> > > the compiler generates, they just want the code to run fast.
> > > This is the market Mill is targeting.
> > >
> > > The real underlying architecture of a CPU is a set of ALU's with a bypass network and a tiny handful
> > > of temp registers, with a limited number of cross connections to the other ALU's. Plus a limited number
> > > of ports to the outside world, which in this case is the register file and the load/store unit.
> > >
> > > Over time and across a CPU portfolio, the design will have different numbers of ALU's and different
> > > numbers of outside ports, and different cross connection network limits, and different numbers of
> > > local temp slots, etc. so you cannot expose the underlying hardware to the instruction set.
> > >
> > > X86 and RISC do not scale greater than six wide on the base hardware achitecture we have.
> > >
> > > The Mill is but the first of many new instruction sets that will be coming out
> > > over the next decade, and with patents lasting 20 years the Mill team hope to prosper
> > > off those patents regards of whether people pick thier specific design.
> > >
> > > Before 1980 instruction sets mattered and there were lots of instruction sets, after 1980 all designs
> > > had plenty of registers and the mantra changed to "instruction sets do not matter". We have hit an
> > > inflection point and the pendulum flips back to instruction sets mattering again. At least until the
> > > decision space has been fully mapped out, and the new set of post RISC designs take over.
> > >
> > > Note that we are also dependent on advancements in LLVM, so the
> > > ideal architecture may be a moving target for a decade.
> > >
> > > I am all in with this prediction, just as I was pointing out the inflection
> > > from fewer and fewwer CPU design firms, to more and more CPU design firms.
> > >
> >
> > Let me try to summarize this all along two dimensions:
> > (a) VLIW works well when dataflow and controlflow are both regular. That's
> > basically what DSPs do, and everyone is happy with using it there.
> >
> > (b) When dataflow is irregular but controlflow is regular across many many independent loops, you're
> > in the domain of GPUs and attempts to exploit that structure are what GPUs are all about. There remains
> > uncertainty as to exactly the optimal way to do this --- just how valuable is the exploiting of the
> > exact same instruction across multiple threads vs somewhat more flexible alternatives? But those are
> > details, the bottom line is these are throughput engines with tons of registers, in-order, non-speculative,
> > and (most importantly) something that is more-or-less equivalent to switch-thread-on-cache-miss. Any
> > pool of lightweight cores (where the critical resource is the bandwidth to RAM) is functionally much
> > the same, so Cell and Larrabee fall in this bucket as far as I'm concerned right now.
> > (Aside, but this is where, IMHO, Apple's "GPU" will be situated". A generic sea of lightweight cores
> > throughput engine speaking AArch64 [perhaps with a few extra special texture calls], and capable of not
> > just GPU functionality but generic highly-multi-threaded functionality with less pain than a GPU.)
> >
> > (c) When dataflow and controlflow are irregular AND you don't have lots of threads to fall back to
> > bail you out, THAT is what I would call "general purpose computation". How can we do that well?
> > OK what do we know? The goal is not to be fast at every piece of code one can fantasize about,
> > but to be fast on the code seen in the real world, using the techniques we know work.
> > The goal is also to work with today's processes and economics, not the constraints
> > of 1990. So area is a negligible constraint, power a massive constraint.
> >
> > Which means you HAVE TO exploit
> > - superscalar/ILP
> > - MLP
> > - control speculation
> > All three are non-negotiable. What, in turn, does this mean?
> >
> > You need a front-end that's as complex as what we have today in state of the art. So lots
> > of SRAMs tracking previous history, and some smart logic to extract from all this the best
> > guess at the next PC to feed the I-cache. We can remove the power cost for many loops (and
> > most time is spent in loops) by having rich loop buffers, and everyone does this.
> >
> > What's not clear to me is the "richness" of extant loop
> > buffers. In particular how well do they handle loops
> > with branches embedded in them? Loop buffers are always portrayed as handling straight-through code runs of
> > say, up to 32 or so instructions, which is depressingly limiting.
> > There may be substantial scope here (remember,
> > we're all about power, not area) for a secondary branch
> > prediction sort of machinery scoped to the loop that
> > allows us to run out of loop buffer (and a much smaller branch prediction engine) for many more, and rather
> > larger, loops. (I'd expect the primary role of THIS branch
> > prediction machinery to be not so much generating
> > new PCs as to be generating some sort of "skip/nullify the next N instructions" vector.
> >
> > Note, as an aside, in this world, trace caches also play no role. Traces are
> > essentially constructed on the fly these days by the branch machinery.
> >
> > Next, control speculation means you need a ROB, or more precisely SOMETHING that holds all your speculative
> > state until its safe to commit. This means you also need either lots of physical registers or something
> > that performs much the same role (like storing the result of each instruction in its ROB slot). So far so
> > good. The ROB per se is cheap-ish, just a queue. The large number of physical registers is problematic,
> > but can be finessed if all you really care about is holding state between when it's calculated and when
> > it's committed. (Eg I can imagine a "ROB" split conceptually into two parts with one part corresponding
> > to state stored in registers, the second corresponding to state stored in the queue. When the "register"
> > ROB is forced to overflow, the oldest instructions spill to the in-queue-store and give up their
> > register. I've never seen a paper with such an idea, but I don't see why it's not feasible.
> > It's even possible, eg, that what IBM call their L2 register file in the POWER8 is such a concept?)
> > Anyway, point is, again at this stage of what we *have to have* for control speculation (which
> > we have to have, by definition for general purpose computing) is still limited to
> > - big front end (but hopefully we can usually run out of the loop buffer)
> > - large ROB (but cheap in both area and power)
> > - not *so* large physical register file
> >
> > Next ILP. Option one is VLIW.
> > The win is less time spent figuring out which instruction interferes
> > with which other instruction (ie simpler issue).
> > Costs are cross-generation compatibility. I don't care about this. As you all know, the world I
> > care about is the Apple world, and I envisage the future as ever more that when you pull in your
> > code from the app store, you get a binary optimized for your particular device from the bitcode
> > that was dumped in the app store. Other people care massively about cross-generation compatibility
> > and even cross-generation performance. That's their cross to bear, but doesn't interest me.
> > Second cost, and this is the one that matters, is there are going to be hiccups in the data delivery, and
> > we can't predict or control these. (Again, by our definition of general computing.) VLIW, or more precisely
> > the giving up of dynamic scheduling that is the POINT of VLIW, can't seem to handle this well.
> >
> > So no VLIW means a stream of "independent" instructions. But this doesn't mean we're doomed. I suspect
> > there's scope for different work at different places to tie instructions together to get at least of the
> > VLIW win. We do some of this dynamically with instruction
> > fusion. I'd be curious to see how much instruction
> > fusion could be moved out to pre-decoding in the I-cache, handled one-time when instructions flow into
> > that cache. Likewise when instructions are placed in the
> > rich loop buffer, is there scope for useful annotation
> > of these instructions to make scheduling cheaper? (You'll see what I mean by this soon.)
> >
> > But yeah, independent superscalar/ILP is nasty and power hungry. Everything we can do to reduce
> > its impact we should. This seems to me to mean constructing the equivalent of VLIW bundles dynamically
> > as much as possible: as much fusion as possible, as rich a loop buffer as possible.
> >
> > Note that everything to this point does NOT require OoO...
> > What I'm trying to get at is instead of this sterile debate about RISC vs CISC
> > or even VLIW vs RICS/CISC, the buzzwords that matter are superscalar, control
> > speculation, MLP, and OoO. All somewhat independent and on a continuum.
> >
> > Finally we want lots of MLP. What does that require? First off we want to have dedicated TLB caches
> > (holding whatever's appropriate from pieces of the higher order tables), prefetchers for these, and
> > two page walkers. (It's just area..., no point in having to wait on this low-power stuff). We also want
> > kickass prefetchers, working with each other not at cross-purposes. But that's all obvious, and it's
> > not enough. We do need the ability for loads (and stores, but of course they are less pressing) to be
> > able to sit in a pending state in such a way that later loads and stores can generate further memory
> > misses. Our ideal state is that once one load misses to RAM, many many other loads also generate misses
> > to RAM, so that our long wait from RAM is effectively amortized over these multiple loads.
> > And this requires OoO :-( :-( :-(
> >
> > So is it game over? Do we have to have a deep issue pool, and a horribly power-hungry waker-upper/scheduler
> > that also, to add insult to injury, probably limits our cycle time?
> > Not necessarily...
> > Why do we want / how do we exploit this OoO? In other words, what
> > instructions tend to slip past each other and rearrange?
> > One theoretical possible source of this slippage is bad instruction scheduling by the compiler. I
> > don't care about this (for the reasons I gave above --- I'm assuming we have extra-CPU machinery that
> > always produces well-scheduled binaries for this particular hardware). So that means the compiler
> > knows the D-cache latency is 4 cycles (or whatever) and handles it appropriately. Likewise it knows
> > how to construct an optimal dependency chain within loops and does the sane thing in unrolling loops.
> > So we don't need a LARGE issue pool to dynamically unroll independent executions of loops.
> > What we do need is
> > - some buffering to handle the hiccups that arise when we miss in D-L1 and have to go to L2
> > - something to handle when we miss in L2
> >
> > To handle this second issue, I commend to your attention the following paper
> > from 2015 which hasn't (IMHO) got nearly the attention it deserves:
> >
> >
> > The big idea is to introduce into the CPU a totally novel (in
> > my experience anyway) form of statistics/speculation.
> > Instructions that miss to RAM are tracked as are their dependencies and the instructions that feed
> > into them. Based on these statistics as they are collected, instruction at the point of RENAME are
> > separated into two streams, the "normal" stream and the stream that are expected not to have anything
> > to do for a long time (because we're waiting on data from RAM).
> > This differs from other superficially similar proposals (and seems to me much more tractable) in that this
> > split is done based on statistics collected, NOT on "dynamic data-flow" meaning that it doesn't require
> > moving out instructions that are already deep in the maelstrom
> > of the OoO core. Of course, like all speculation,
> > the stats are occasionally wrong, but they're correct ENOUGH of the time that this appears to be a big win.
> > In particular it means that for most code most of the time, you just need an issue pool large enough to
> > handle the small-scale re-ordering that I described above
> > (miss to L2 for example) and to generate the "usual"
> > amount of MLP that can be generated, which removes much of
> > the cost of issue. Clustering (and, again statistics!,
> > cluster steering predictors) help remove much of the rest of the cost.
> >
> > So where does this leave us?
> > Two nasties that I have NOT covered are load queue and store queue. Those remain horribly expensive.
> > ARM does a great job of simplifying this to some extent through
> > the load-pair/store pair mechanism. Essentially
> > what one would like is ways to say something like "this load/store doesn't interact with anything else
> > that you, the core, need to care about". That's clearly tough to specify in any sort of useful way, for
> > either the compiler or in the instruction set. Load/store pair helps insofar as it creates a larger unit
> > to be consider thus reducing the number of cross-pairs that need to be considered. Vector loads/stores
> > likewise help, for the same reason. One could imagine things like adding load/store triple and quadruple
> > instructions (let's ignore other issues like bus widths or encoding for now) but would that buy us much?
> > I've not seen numbers for how often non-vector runs of three or four successive same-sized objects are
> > loaded or stores, but I suspect the win after pairs is pretty minimal.
> >
> > However, taking a hint from the paper I referenced above, what if we
> > - maintained statistics for how often these pairs collided
> > - based on these statistics steered the "apparently safe"
> > loads/stores down a path that was SAFE (everything
> > can be un-speculated if necessary) but optimistic in its assumption (all these guys never collided before,
> > so we won't bother testing them again, we'll just do a final verification at commit)?
> >
> > This would allow us to similarly create the expensive (but no-longer so deep) standard load and
> > store queues, and less expensive much simpler structures for the "expected safe" loads+stores.
> > (I haven't really though this through, but I'm assuming that somehow we can arrange these structures
> > in such a way that they can be slow but large --- eg n-way associative and banked rather than large
> > CAMs because the hope is that most of the time, most loads/stores both don't interfere and are
> > accurately predicted as not interfering, so that we can afford that all this cross-checking happens
> > cycles after the actual generation of the load-data and having to replay is rare).
> >
> > So, what's the point of this long long exegesis?
> > - To deal with the kind of code that I think most of us are interested in (the "general
> > purpose code") I think you have to implement the things I've suggested
> > + control speculation (and thus recovery mechanism)
> > + superscalar (and thus DYNAMIC scheduling to make sure instructions don't tramp on each other)
> > + MLP (which forces OoO)
> >
> > BUT there is still some under-utilized scope for reducing the expensive parts of the OoO+speculative
> > complex through exploiting the way real code behaves. I've suggested this through the Long Term
> > Parking paper, and through a hope that a similar idea could help with load/store queues.
> >
> > And so, to Mill. Unfortunately most of what Mill does doesn't seem to me especially relevant to everything
> > I've laid out. Yeah, things like register rename and so on are a hassle, but if you believe deep control
> > speculation is necessary, you have to have somewhere to hold all your temporary state anyway, and
> > I'm not sure that minor details like the belt and so referencing by "three instructions down and two
> > over" (with the hassle THAT generates when you go OoO --- which memory unpredictability forces on
> > you anyway) are any better. It seems to me BOTH ways you're going to have to do dynamic renaming to
> > deal with the dynamic uncertainties, and you're going to require a large pool of something to hold
> > pending but uncommitted state. Likewise the crazy wide instruction fetch/issue, I just don't see it
> > as being relevant to THIS world I've laid out. For the DSP world, maybe?
> >
> > Finally one final thing. The world I've described above tries to exploit a variety of correlations
> > across program execution, and generally does so through a variety to local SRAMs that are recording
> > those correlations. IF your goal is a latency engine, I don't see adding SMT to this as a useful
> > addition. In the worst case you destroy many of the correlations. Even if you're smart enough to
> > tag EVERYTHING with a threadID, you're basically halving (or worse) the available size of all these
> > data structures. Which means that they're either no longer optimally sized, or you're paying extra
> > power costs (which are sometimes quadratic) in the single-threaded case.
> > I don't think this is a sensible ENGINEERING trade-off in
> > a world where area doesn't matter but power-density
> > does. Now certain legacy business models may view things
> > differently, but that doesn't interest me; I expect
> > engineering to prevail which means future business models
> > will have to operate differently. You can see this
> > already insofar as ARM doesn't think it's some sort of big
> > deal to sell you eight (or ten...) cores rather than
> > making a fuss about segmenting buyers into 2-core, 4-core,
> > 6-core, 8-core camps. Likewise if you're selling parts
> > whose selling point is that they are throughput engines,
> > a different calculus applies. But I'm operating on the
> > assumption that for future designs it makes more sense
> > to have a FULLY optimized latency engine or two and a
> > FULLY optimized throughput engine (what I suggested earlier
> > as what I expect from Apple's "GPU") rather than
> > trying to create something neither fish nor fowl that's
> > only an adequate latency engine (but runs hotter than
> > it needs to because its structures are larger than optimal
> > in single-threaded mode) and only an adequate throughput
> > engine (but runs slower than it needs to because its structures are too small in SMT mode).
> >
> > Yeah there's a lot here. And yeah, it's opinionated. And
> > yeah, it's somewhat slanted to the needs of a company
> > you may not care about, with zero concern for how these ideas might apply to x86 or any other company.
> > But, jesus, isn't the plan of record that I've laid out --- disentangling OoO, MLP, ILP, and
> > speculation, VASTLY more interesting than yet another argument about what RISC "really" is, and
> > the merits or otherwise of implementing a CPU given the constraints of 180nm technology?
> >
> > As Ireland says, over and out.
> Yeah, that was a long post.
> Just to be clear with the simpler idea I was trying to get across, a micro thread of three stack
> ops dispatched to a ALU does not generate three results that need to be renamed like x86/RISC,
> you get one result to rename, or none in many cases as the result may be used by a branch.
> With a quarter of the rename needs the rename limit goes away, transistor and power loss is reduced, etc.
> But this requires a new instruction set, which is far less wasteful with less bogus state to track. There are
> lots of different ways to do this, if you stay RISC you can split your register file four ways kind of like the
> 68000. I also looked at a 64bit 6502 like zero page approach, but that was more for a GPU like engine.

You get some of this through op fusion, although fusion is limited to cases that don't generate a visible intermediate result. You get some of it (reduced number of physical registers, though not reduced number of ports) through my suggestion that substantial amounts of pre-commit state can be held in non-register storage.

With both those out the way, I think the issue becomes empirical:
of the various possible cycle-limiting pain points in existing OoO, is rename (under the optimal conditions I describe above) still a cycle-limiter? If not, because the cycle-limiter is the wakeup-schedule loop, then is it a moot point? How bad is the power spent?

Your suggestion providing for a pseudo-stack in this case is cute, but I suspect it's suboptimal. There are certainly cases where the value of registers is that they can stick around for a long time, and that they can be addressed more or less "randomly". (Specialized, sure, but I think of a radix-8 FFT that I wrote for PPC to handle the 64 and 512 point FFTs inside AAC audio, where I just managed to fit everything into the 32 FP registers available, all accessed using a more or less random pattern...)
I think what we're both suggesting in various ways is that you want to know when a register becomes dead so that it can be recycled. Superficially a stack language (likely augmenting registers) does that; in practice it hasn't worked out great for Intel on either the int or the x87 side. (Though of course those were both not exactly what you propose...)
I suspect that what one REALLY wants is the ability to say something like "this register only needs to live until the instruction three slots down from me" and have the OoO engine use that info as it sees fit.

So how can we utilize that?
One possibility is we don't need perfection. Just define a single bit that's the "temporary result register value" bit. If clear, the register behaves like normal, if set the register doesn't have to persist past some set value (32 instructions?) of the current point. This seems like an area worth an MS investigation as to how common this situation is, and how much value exploiting it could generate. It does, obviously require an ISA change --- but one that's a lot less "boil the ocean" than augmenting registers with a set of contextually varying stacks that are continually being created and destroyed, both on the tools side and within the CPU.

If there is substantial value, then, once again, the secondary question arises: does tracking this situation (in loops, if not for general code) provide any value? If a few iterations of the loop suggest that a register is "temporary", can we exploit that in a way that can be undone (like all speculation) when necessary, but that in the common case allows for lower power? Of course in both these cases you have to define what EXACTLY the contract means! Presumably your "temporary" register has to persist across interruptions and context switches!
It can be used to shrink the number of physical registers. What you really want, of course, is some sort of guarantee that its value can ALWAYS be picked up off the results bus, so it doesn't need physical register storage, but I don't see how you can be confident of that really in any situation --- certainly not with registers, but also not with "stack-named-registers" or belt or anything else. Where are going to allow/prevent interrupts from happening? Even VLIW type ISAs don't offer guarantees about interrupts *between* the instruction words, and that's what we're interested in, the data flow between instructions and later instructions. And once there's a chance that physical storage is necessary, there has to be machinery naming that storage, so a rename stage of some sort, no?

Here's another idea. When we generate the names, we don't HAVE to perform say 4 renames per cycle (for a 4-wide CPU). We could block the physical registers in groups of 4, allocate 4 at once as X.0, X.1, X.2 and X3. Then this set of 4 remains "busy" until all four elements are freed. That's perhaps sub-optimal today when the number of physical registers today is bound up with the size of the ROB. (Now that I think about it, is this the REAL reason for the grouping IBM performed from POWER4 onwards? I never found what I considered to be a reasonable explanation for that. The ROB, and retire, are not so complex that they need that sort of trick --- but block-allocation of a set of physical registers as a single rename operation WOULD sorta match what they're doing?)
Moreover if the various suggestions I've offered for freeing registers ASAP are utilized, then it becomes a lot more feasible (especially if we learn, as I suspect is true, that most instructions flow through issue very rapidly, and the ones that hang around for a long time are being, as I already explained, segregated in long term parking), and so rename becomes vastly cheaper. You can of course go half-way with this --- allocate physical registers as pairs, so you have 2 "renames" not 4 on a 4-wide, or as triplets, giving you 2 "renames" on a 6-wide Cyclone-style core.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Apple confirms that they are ditching Imagination within two yearsAnon04/03/17 01:21 AM
  Apple confirms that they are ditching Imagination within two yearsMichael S04/03/17 01:40 AM
    MIPSAnon04/03/17 01:48 AM
      Microprocessor WITH interlocked Pipeline Stages, please rest in peace!Heikki Kultala04/03/17 03:59 AM
        Microprocessor WITH interlocked Pipeline Stages, please rest in peace!RichardC04/03/17 07:17 AM
          RISC *was* science, not religionRichardC04/03/17 05:49 PM
            RISC *was* science, not religionIreland04/03/17 06:12 PM
              RISC *was* science, not religionbakaneko04/03/17 11:40 PM
            RISC *was* science, not religionLinus Torvalds04/03/17 06:25 PM
              RISC *was* science, not religionRichardC04/03/17 06:45 PM
                RISC *was* science, not religionanon04/03/17 08:37 PM
                  RISC *was* science, not religionbakaneko04/04/17 12:00 AM
                    RISC *was* science, not religionMichael S04/04/17 01:23 AM
                    RISC *was* science, not religionanon04/04/17 01:51 AM
                      RISC *was* science, not religionbakaneko04/04/17 04:17 AM
                        RISC *was* science, not religionanon04/04/17 06:39 AM
                RISC *was* science, not religionRichardC04/04/17 06:02 AM
                  RISC *was* science, not religionMichael S04/04/17 07:05 AM
                    RISC *was* science, not religionRichardC04/04/17 08:06 AM
                      Try not to aim for one point on the curve!David Kanter04/05/17 10:15 PM
                        Try not to aim for one point on the curve!RichardC04/06/17 04:11 AM
                          Try not to aim for one point on the curve!Michael S04/06/17 06:17 AM
                            Try not to aim for one point on the curve!Ireland04/06/17 10:16 AM
                            Try not to aim for one point on the curve!RichardC04/06/17 10:25 AM
                              Influence of Palm and Blackberry on Smaller DevicesIreland04/06/17 10:45 AM
                          Try not to aim for one point on the curve!Ireland04/06/17 10:11 AM
                          RISC not needed for smartphones and tabletsHeikki Kultala04/06/17 10:39 PM
                        Try not to aim for one point on the curve!coppice04/07/17 03:52 AM
                          Try not to aim for one point on the curve!Michael_S04/07/17 04:41 AM
                  RISC *was* science, not religionbakaneko04/04/17 07:55 AM
                    RISC *was* science, not religionIreland04/04/17 08:59 AM
                    RISC *was* science, not religionanon04/05/17 03:53 AM
                      RISC *was* science, not religionBrett04/05/17 09:25 PM
                        RISC *was* science, not religionanon04/06/17 02:36 AM
                          RISC *was* science, not religionBrett04/06/17 09:36 PM
                            RISC *was* science, not religionanon04/07/17 07:05 AM
                              RISC *was* science, not religionBrett04/08/17 12:02 AM
                                RISC *was* science, not religiondmcq04/08/17 04:45 AM
                                RISC *was* science, not religionanon04/08/17 08:39 AM
                                  (disappointing) Mill progressUngo04/08/17 01:07 PM
                                    (disappointing) Mill progressMichael S04/08/17 01:36 PM
                                      (disappointing) Mill progresswumpus04/08/17 06:44 PM
                                      I don't understand why they are aiming for CPU instead for DSP (NT)Heikki Kultala04/08/17 10:16 PM
                                        I don't understand why they are aiming for CPU instead for DSPCoppice04/08/17 10:40 PM
                                          I don't understand why they are aiming for CPU instead for DSPCoppice04/08/17 11:32 PM
                                            I don't understand why they are aiming for CPU instead for DSPwumpus04/09/17 09:41 AM
                                          I don't understand why they are aiming for CPU instead for DSPHeikki Kultala04/09/17 09:49 PM
                                        I don't understand why they are aiming for CPU instead for DSPMichael S04/09/17 03:15 AM
                                          I don't understand why they are aiming for CPU instead for DSPanon04/09/17 07:01 AM
                                  RISC *was* science, not religionBrett04/09/17 12:16 AM
                                    RISC *was* science, not religionanon04/09/17 09:30 AM
                                      RISC *was* science, not religionMichael S04/09/17 10:04 AM
                                        RISC *was* science, not religionanon04/09/17 11:06 AM
                                        RISC *was* science, not religionBrett04/09/17 10:53 PM
                                          RISC *was* science, not religionDoug S04/10/17 02:03 PM
                                            RISC *was* science, not religionMichael_S04/11/17 10:14 AM
                                      RISC *was* science, not religionBrett04/10/17 12:01 AM
                                        RISC *was* science, not religionanon04/10/17 02:11 AM
                                          RISC *was* science, not religionDoug S04/11/17 03:31 PM
                                            RISC *was* science, not religionBrett04/11/17 10:06 PM
                                            RISC *was* science, not religionanon04/12/17 04:49 AM
                                RISC *was* science, not religionGabriele Svelto04/09/17 01:55 AM
                                  RISC *was* science, not religionMegol04/10/17 10:42 AM
                                    RISC *was* science, not religionGabriele Svelto04/10/17 02:12 PM
                                      RISC *was* science, not religionMegol04/11/17 12:23 PM
                                        RISC *was* science, not religionGabriele Svelto04/11/17 01:49 PM
                                          The Mill is not dataflowPaul A. Clayton04/12/17 04:43 AM
                                            The Mill is not dataflowAdrian04/12/17 11:21 AM
                                              Name rather than address for Mill pick-up loads?Paul A. Clayton04/12/17 07:35 PM
                                                Name rather than address for Mill pick-up loads?Adrian04/12/17 11:51 PM
                                                  Fractional bits for instruction encodingook04/13/17 01:56 AM
                                                    Fractional bits have been used for RegID encoding (NT)Paul A. Clayton04/13/17 04:04 AM
                                                    Fractional bits for instruction encodingMegol04/13/17 05:21 AM
                                                      fractional bitsRichardC04/13/17 06:20 AM
                                                        fractional bitsMegol04/15/17 06:22 AM
                                                          fractional bitsRichardC04/15/17 10:58 AM
                                                            fractional bitsAdrian04/16/17 04:08 AM
                                                              fractional bitsdmcq04/16/17 05:04 AM
                                                              fractional bitsMichael_S04/16/17 05:27 AM
                                                                The Mill spills load buffers on function callsPaul A. Clayton04/16/17 12:44 PM
                                                                  The Mill spills load buffers on function callsRichardC04/16/17 02:36 PM
                                                                    A specialized cache for spillsPaul A. Clayton04/16/17 04:52 PM
                                                                      A specialized cache for spillsRichardC04/17/17 01:16 AM
                                                                        The cycle-predictable domainRichardC04/17/17 08:29 AM
                                                                          The cycle-predictable domainMichael S04/17/17 02:35 PM
                                                                            The cycle-predictable domainRichardC04/17/17 03:01 PM
                                                                              The cycle-predictable domainMichael S04/17/17 03:37 PM
                                                                                The cycle-predictable domainRichardC04/17/17 05:25 PM
                                                                                  The cycle-predictable domainRichardC04/20/17 09:10 AM
                                                                                    The cycle-predictable domainMichael S04/21/17 05:15 AM
                                                                                      sgemm detailsRichardC04/21/17 06:09 AM
                                                                                        sgemm detailsRichardC04/21/17 09:45 AM
                                                                                          sgemm detailsRichardC04/21/17 11:27 AM
                                                                                            sgemm detailsMichael S04/22/17 10:43 AM
                                                                                              sgemm detailsRichardC04/23/17 06:18 AM
                                                                                                sgemm detailsanon04/23/17 06:51 AM
                                                                                                  sgemm detailsMichael S04/23/17 06:59 AM
                                                                                                sgemm detailsMichael S04/23/17 06:55 AM
                                                                                        Mill "registers"Michael S04/22/17 11:45 AM
                                                                          The cycle-predictable domainJacob Marley04/17/17 09:28 PM
                                                                            The cycle-predictable domainJacob Marley04/17/17 09:28 PM
                                                                            The cycle-predictable domainMaynard Handley04/17/17 10:00 PM
                                                                            OoO window and cachesRichardC04/18/17 06:53 AM
                                                                          Mill made more sense in 2003RichardC04/18/17 02:48 PM
                                                                            Mill made more sense in 2003Megol04/18/17 03:24 PM
                                                                              Mill made more sense in 2003RichardC04/18/17 04:46 PM
                                                                                Mill made more sense in 2003Megol04/19/17 10:02 AM
                                                                                  Mill made more sense in 2003RichardC04/19/17 01:22 PM
                                                                                    Mill made more sense in 2003anon04/20/17 06:35 AM
                                                                                      Mill made more sense in 2003RichardC04/20/17 09:39 AM
                                                                                        Mill made more sense in 2003anon04/20/17 12:15 PM
                                                                                          Mill made more sense in 2003RichardC04/20/17 01:10 PM
                                                                                            Mill made more sense in 2003anon04/20/17 03:27 PM
                                                                                              Mill made more sense in 2003RichardC04/20/17 07:33 PM
                                                                                                Mill made more sense in 2003anon04/21/17 03:35 AM
                                                                                                  Mill made more sense in 2003RichardC04/21/17 05:25 AM
                                                                                                    DenverRichardC04/21/17 05:54 AM
                                                                                                      Denverdmcq04/22/17 04:57 AM
                                                                                                        DenverMichael S04/22/17 11:58 AM
                                                                                                          Denverdmcq04/22/17 12:57 PM
                                                                                                            DenverRichardC04/22/17 02:41 PM
                                                                                                              Denverdmcq04/22/17 03:35 PM
                                                                                                                Denverdmcq04/22/17 03:41 PM
                                                                                                                  loopsRichardC04/23/17 06:03 AM
                                                                                                                    loopsanon04/23/17 06:35 AM
                                                                                                            DenverMichael S04/22/17 03:41 PM
                                                                                                    Mill made more sense in 2003anon04/21/17 07:55 AM
                                                                                                      Mill made more sense in 2003RichardC04/21/17 08:56 AM
                                                                                                        Mill made more sense in 2003anon04/21/17 11:46 AM
                                                                                                          Mill made more sense in 2003RichardC04/21/17 02:13 PM
                                                                                                            Mill made more sense in 2003anon04/21/17 02:21 PM
                                                                                                      Mill made more sense in 2003none04/21/17 09:03 AM
                                                                                                      Mill made more sense in 2003NoSpammer04/21/17 12:40 PM
                                                                                                        Mill made more sense in 2003anon04/21/17 01:19 PM
                                                                                                        Mill made more sense in 2003Megol04/22/17 04:42 AM
                                                                                                          Mill made more sense in 2003RichardC04/22/17 11:07 AM
                                                                                              Actually, Mill scratchpad is more like 1 cycleHenry S04/21/17 02:27 PM
                                                                                            Mill made more sense in 2003Jacob Marley04/20/17 10:14 PM
                                                                                              Mill made more sense in 2003Jacob Marley04/20/17 10:14 PM
                                                                                                Mill made more sense in 2003Jacob Marley04/20/17 10:15 PM
                                                                                              OoOE processor and virtual function callsHeikki kultala04/20/17 10:59 PM
                                                                                                OoOE processor and virtual function callsJacob Marley04/21/17 01:12 AM
                                                                                                  OoOE processor and virtual function callsMichael_S04/21/17 03:04 AM
                                                                                                OoOE processor and virtual function callsRichardC04/21/17 06:26 AM
                                                                                            Mill made more sense in 2003Michael_S04/21/17 03:37 AM
                                                                                              Mill made more sense in 2003Gabriele Svelto04/22/17 03:17 PM
                                                                                        Mill is optimized for frequent callsHenry S04/21/17 02:27 AM
                                                                                          spillerRichardC04/21/17 07:53 AM
                                                                                            spiller documentationRichardC04/21/17 08:04 AM
                                                                                            spillerSymmetry04/21/17 08:47 AM
                                                                                              spillerSymmetry04/21/17 08:51 AM
                                                                                        Mill made more sense in 2003wumpus04/21/17 07:59 AM
                                                                                  Mill made more sense in 2003wumpus04/20/17 07:58 AM
                                                                              Mill made more sense in 2003anon04/18/17 08:02 PM
                                                                          virtual method callsRichardC04/19/17 08:50 AM
                                                                fractional bitsrwessel04/17/17 02:14 AM
                                                                  fractional bitsMichael S04/17/17 12:50 PM
                                                                    fractional bitsEugene Nalimov04/17/17 08:25 PM
                                                              fractional bitsMegol04/16/17 03:05 PM
                                                                fractional bitsdmcq04/17/17 03:04 AM
                                                                  fractional bitsGabriele Svelto04/17/17 10:09 AM
                                                                    fractional bitsMaynard Handley04/17/17 11:53 AM
                                                                      fractional bitsanon04/17/17 02:29 PM
                                                                Excellent exampleHenry S04/21/17 02:02 PM
                                                              fractional bitsanon04/16/17 05:31 PM
                                                                OoO instruction windowPaul A. Clayton04/17/17 06:43 PM
                                                                  OoO instruction windowanon04/17/17 07:57 PM
                                                                    OoO instruction windowMaynard Handley04/17/17 10:16 PM
                                                                      OoO instruction windowanon04/18/17 02:51 AM
                                                                        OoO instruction windowwumpus04/19/17 07:16 AM
                                                                    Initiating post-return loads earlyPaul A. Clayton04/18/17 08:39 AM
                                                                      Initiating post-return loads earlyanon04/18/17 06:28 PM
                                                                        Software assisted prefetchingPaul A. Clayton04/18/17 08:13 PM
                                                                          Software assisted prefetchingMaynard Handley04/18/17 10:04 PM
                                                                            Software assisted prefetchingMichael S04/19/17 01:49 AM
                                                              fractional bitsUngo04/17/17 08:03 PM
                                                            fractional bitsMegol04/16/17 02:33 PM
                                                              fractional bitsRichardC04/16/17 02:43 PM
                                                          fractional bitsBrett04/15/17 12:48 PM
                                                            RISC warsMichael S04/15/17 01:04 PM
                                                              RISC warsBrett04/15/17 04:18 PM
                                                                RISC warsdmcq04/16/17 04:36 AM
                                                                  RISC warsBrett04/16/17 03:02 PM
                                                                    RISC warsMaynard Handley04/16/17 05:48 PM
                                                                      RISC warsBrett04/16/17 07:56 PM
                                                                        RISC warsMaynard Handley04/16/17 09:45 PM
                                                                          RISC warsBrett04/17/17 01:51 AM
                                                                      RISC warsSimon Farnsworth04/17/17 05:51 AM
                                                                        RISC warsdmcq04/17/17 06:24 AM
                                                                          RISC warsBrett04/22/17 02:36 PM
                                                                            RISC warsMaynard Handley04/22/17 03:14 PM
                                                                              RISC warsBrett04/22/17 05:54 PM
                                                                                RISC warsMaynard Handley04/22/17 09:17 PM
                                                                                  POWER8 - frequency, rename widthMichael S04/23/17 01:47 AM
                                                                                RISC warsMichael S04/23/17 02:25 AM
                                                                    RISC warsdmcq04/17/17 02:55 AM
                                                    Fractional bits for instruction encodingdmcq04/13/17 06:35 AM
                                                      Sounds like a FP counter with random rounding (NT)Paul A. Clayton04/13/17 07:08 PM
                                                        Sounds like a FP counter with random roundingdmcq04/14/17 12:35 PM
                                          RISC *was* science, not religionMegol04/12/17 03:13 PM
                                            Mill load buffer and spillPaul A. Clayton04/12/17 07:02 PM
                              RISC *was* science, not religionMichael S04/09/17 03:51 AM
                                RISC *was* science, not religionanon04/09/17 08:30 AM
                  ARM vs RISC religionHeikki Kultala04/04/17 07:58 AM
                    religious vs atheist or SF Bay Area vs Rest of the World (NT)Michael S04/04/17 08:25 AM
                    ARM vs RISC religionRichardC04/04/17 08:44 AM
                      ARM vs RISC religionEtienne04/04/17 09:22 AM
                        ARM vs RISC religionRichardC04/04/17 09:39 AM
                          ARM vs RISC religionExophase04/04/17 07:54 PM
                            that's a neat trick! (NT)RichardC04/04/17 08:34 PM
                    ARM vs RISC religiondmcq04/04/17 09:37 AM
                    ARM vs RISC religionwumpus04/05/17 07:14 AM
                  RISC *was* science, not religionIreland04/04/17 09:14 AM
                    RISC *was* science, not religionIreland04/04/17 03:12 PM
                      RISC *was* science, not religionIreland04/04/17 03:14 PM
                  RISC *was* science, not religionLinus Torvalds04/04/17 11:10 AM
                    RISC *was* science, not religionMichael S04/04/17 11:24 AM
                      RISC *was* science, not religionExophase04/04/17 10:05 PM
                        RISC *was* science, not religionMichael S04/05/17 01:58 AM
                          RISC *was* science, not religionExophase04/05/17 11:07 AM
                            RISC *was* science, not religionMichael S04/05/17 03:38 PM
                          Load delay slot new value after cache missPaul A. Clayton04/06/17 10:29 AM
                            Load delay slot new value after cache missExophase04/06/17 03:05 PM
                      unspcified behaviour load delay slot pessimalityHeikki Kultala04/04/17 11:14 PM
                      RISC *was* science, not religionSimon Farnsworth04/06/17 05:18 AM
                        RISC *was* science, not religionRichardC04/06/17 09:54 AM
                          RISC *was* science, not religionSimon Farnsworth04/06/17 11:51 AM
                        RISC *was* science, not religiondmcq04/06/17 03:55 PM
                          RISC *was* science, not religionEtienne04/07/17 04:36 AM
                    RISC *was* science, not religionRichardC04/04/17 11:58 AM
                      RISC *was* science, not religionIreland04/04/17 03:20 PM
                      RISC *was* science, not religionIreland04/04/17 03:40 PM
                        RISC *was* science, not religionbakaneko04/05/17 12:52 AM
                          RISC *was* science, not religionIreland04/05/17 01:04 PM
                      RISC *was* science, not religiongallier204/05/17 05:06 AM
                        RISC *was* science, not religionRichardC04/05/17 09:14 AM
                          RISC *was* science, not religionSimon Farnsworth04/05/17 11:01 AM
                          RISC *was* science, not religionSeni04/05/17 12:26 PM
                          RISC *was* science, not religionDavid Hess04/05/17 11:36 PM
                            RISC *was* science, not religionRichardC04/06/17 12:32 PM
                              RISC *was* science, not religionExophase04/06/17 03:07 PM
                                RISC *was* science, not religionLinus Torvalds04/06/17 03:27 PM
                                  Intel x86 registers to the rescue!Mark Roulo04/06/17 03:45 PM
                                    Intel x86 registers to the rescue!Linus Torvalds04/06/17 04:25 PM
                                      Intel x86 registers to the rescue!John Yates04/06/17 05:51 PM
                                      Intel x86 registers to the rescue!David Hess04/08/17 06:49 AM
                                        Intel x86 registers to the rescue!Ireland04/08/17 04:47 PM
                                          Intel x86 registers to the rescue!wumpus04/08/17 06:51 PM
                                            Intel x86 registers to the rescue!David Hess04/09/17 03:57 PM
                                        Memory laneJohn Yates04/11/17 02:24 PM
                                          Memory lanesomeone04/12/17 06:27 AM
                                            Memory laneJohn Yates04/12/17 03:01 PM
                                          Memory laneIreland04/12/17 11:23 AM
                                    Intel x86 registers to the rescue!dmcq04/07/17 12:47 AM
                              RISC *was* science, not religionDavid Hess04/08/17 06:16 AM
                          RISC *was* science, not religiongallier204/05/17 11:49 PM
                            6502 = accumulator machine (NT)Wilco04/06/17 03:22 AM
                          RISC *was* science, not religiongallier204/06/17 12:12 AM
                            same difference ...RichardC04/06/17 12:57 PM
                    RISC *was* science, not religionRonald Maas04/04/17 09:04 PM
                      RISC *was* science, not religiondmcq04/05/17 12:03 PM
                        RISC *was* science, not religionAdrian04/05/17 02:24 PM
                      RISC *was* science, not religiongallier204/06/17 12:33 AM
                        RISC *was* science, not religionRonald Maas04/08/17 09:07 AM
                    RISC *was* science, not religionJohn Yates04/05/17 03:39 PM
                      RISC *was* science, not religionRichardC04/07/17 03:30 PM
                        RISC *was* science, not religionwumpus04/08/17 08:41 AM
                          RISC *was* science, not religionLinus Torvalds04/08/17 11:43 AM
                            RISC *was* science, not religionanon04/08/17 08:53 PM
                              RISC *was* science, not religionLinus Torvalds04/09/17 08:52 AM
                            VAX/VMS compatibilityRichardC04/09/17 07:54 AM
                              VAX/VMS compatibilityIreland04/09/17 08:19 AM
                              VAX/VMS compatibilityMichael S04/09/17 08:20 AM
                                VAX/VMS compatibilityRichardC04/09/17 08:32 AM
                                  VAX/VMS compatibilitydmcq04/09/17 08:47 AM
                                    I suppose, you are only familiar with British mainfraimes (NT)Michael S04/09/17 08:55 AM
                                      I suppose, you are only familiar with British mainfraimesdmcq04/09/17 05:12 PM
                                    VAX/VMS compatibilityIreland04/09/17 09:08 AM
                                    VAX/VMS compatibilityrwessel04/09/17 09:51 AM
                                      VAX/VMS compatibilityIreland04/09/17 12:35 PM
                                        VAX/VMS compatibilityanon04/09/17 06:24 PM
                                          VAX/VMS compatibilityIreland04/09/17 06:47 PM
                                            VAX/VMS compatibilityanon04/09/17 07:29 PM
                                              VAX/VMS compatibilityIreland04/09/17 07:43 PM
                                              Ireland = AI botanonymou504/10/17 05:21 AM
                                                That joke is getting old (NT)Anon04/11/17 01:23 AM
                                                  It isn't 100% a joke.Mark Roulo04/11/17 07:13 AM
                                                    It isn't 100% a joke.Michael_S04/11/17 10:19 AM
                                                      It isn't 100% a joke.Ireland04/11/17 10:48 AM
                                                      It isn't 100% a joke.anonymou504/12/17 09:40 PM
                                                    It isn't 100% a joke.Dan Downs04/11/17 04:05 PM
                                                      Shaka, when the walls fell (NT)Darmok04/12/17 12:19 AM
                                                      It isn't 100% a joke.Brendan04/13/17 05:34 AM
                                                        Can Someone Fix "Greater Than/Less Than" Handling Bugs??Brendan04/13/17 05:38 AM
                                                          6th decadeMichael S04/13/17 06:34 AM
                                                            6th decadeIreland04/13/17 10:17 AM
                                                        It isn't 100% a joke.Gabriele Svelto04/15/17 08:14 AM
                                                          It isn't 100% a joke.dmcq04/16/17 05:09 AM
                                                            It isn't 100% a joke.Brendan04/16/17 03:01 PM
                                                              The less loquacious left it alone (NT)Anon04/18/17 12:49 AM
                                                To Wit, many here..John H04/12/17 11:40 AM
                                                  To Wit, many here..Ireland04/12/17 11:54 AM
                                      VAX/VMS compatibilitydmcq04/09/17 05:02 PM
                                        VAX/VMS compatibilityIreland04/09/17 05:19 PM
                                        VAX/VMS compatibilityrwessel04/09/17 10:20 PM
                                          VAX/VMS compatibilitywumpus04/10/17 06:14 AM
                                            VAX/VMS compatibilityrwessel04/10/17 08:10 AM
                                            VAX/VMS compatibilitydmcq04/10/17 10:11 AM
                                          VAX/VMS compatibilityJohn Yates04/12/17 07:42 PM
                                            VAX/VMS compatibilityrwessel04/12/17 09:19 PM
                                    VAX/VMS compatibilityJohn Yates04/12/17 09:41 PM
                                      VAX/VMS development - thank you, JohnMichael S04/13/17 04:54 AM
                                        VAX/VMS development - thank you, JohnRob Thorpe04/14/17 08:19 AM
                                          VAX/VMS development - thank you, JohnJohn Yates04/14/17 04:20 PM
                                      VAX/VMS compatibilitydmcq04/13/17 06:23 AM
                        RISC *was* science, not religionanon04/08/17 11:04 AM
                          RISC *was* science, not religionIreland04/08/17 12:01 PM
                          RISC *was* science, not religionwumpus04/08/17 05:57 PM
                            RISC *was* science, not religionanon04/09/17 10:49 AM
                          RISC *was* science, not religionRicardo B04/09/17 04:15 PM
                            RISC *was* science, not religionanon04/09/17 11:07 PM
                              RISC *was* science, not religionRicardo B04/10/17 02:17 AM
                                RISC *was* science, not religionanon04/10/17 09:01 AM
                                  RISC *was* science, not religionRicardo B04/10/17 11:27 AM
                                    RISC *was* science, not religionanon04/10/17 03:25 PM
                                      RISC *was* science, not religionRicardo B04/10/17 05:12 PM
                                        RISC *was* science, not religionanon.104/10/17 10:54 PM
                                          RISC *was* science, not religionRicardo B04/11/17 03:14 AM
                                            RISC *was* science, not religiondmcq04/11/17 03:44 AM
                                            RISC *was* science, not religionanon.104/11/17 09:03 AM
                                              RISC *was* science, not religionWilco04/11/17 02:04 PM
                                                RISC *was* science, not religionanon04/11/17 09:07 PM
                                              RISC *was* science, not religionRicardo B04/11/17 02:15 PM
                                                RISC *was* science, not religionrwessel04/11/17 05:38 PM
                                                RISC *was* science, not religionanon04/11/17 08:36 PM
                                                  RISC *was* science, not religionRicardo B04/12/17 02:01 AM
                                                  RISC *was* science, not religionGabriele Svelto04/12/17 02:38 AM
                                                  RISC *was* science, not religionTravis04/12/17 12:20 PM
                                                RISC *was* science, not religionanon.104/11/17 10:54 PM
                                                  RISC *was* science, not religionRicardo B04/12/17 01:52 AM
                                                  RISC *was* science, not religiondmcq04/12/17 04:27 AM
                                                    RISC *was* science, not religionanon.104/12/17 08:43 AM
                                                      RISC *was* science, not religionanon.104/12/17 11:03 AM
                                              RISC *was* science, not religionMichael S04/11/17 02:32 PM
                                                RISC *was* science, not religionanon.104/11/17 10:45 PM
                                                  RISC *was* science, not religionMichael S04/12/17 10:07 AM
                                                RISC *was* science, not religiongpd04/12/17 02:31 AM
                                                  RISC *was* science, not religionTravis04/12/17 11:16 AM
                                                    RISC *was* science, not religionMichael S04/12/17 11:27 AM
                                                      RISC *was* science, not religionTravis04/12/17 12:02 PM
                                                        RISC *was* science, not religionMichael S04/12/17 12:46 PM
                                                          RISC *was* science, not religionTravis04/12/17 03:41 PM
                                                RISC *was* science, not religionTravis04/12/17 11:33 AM
                                                  RISC *was* science, not religionMichael S04/12/17 12:56 PM
                                                    RISC *was* science, not religionTravis04/12/17 04:22 PM
                                            RISC *was* science, not religionMichael S04/11/17 12:08 PM
                                        RISC *was* science, not religionanon04/11/17 02:10 AM
                                          RISC *was* science, not religionRicardo B04/11/17 03:28 AM
                                            RISC *was* science, not religionanon04/11/17 04:46 AM
                                              RISC *was* science, not religionmatthew04/11/17 08:59 AM
                                                RISC *was* science, not religionanon04/11/17 01:28 PM
                                        RISC *was* science, not religionMichael S04/11/17 11:41 AM
                                    RISC *was* science, not religionanon.104/10/17 08:03 PM
                                      RISC *was* science, not religionRicardo B04/11/17 03:47 AM
              RISC *was* science, not religionbakaneko04/03/17 11:45 PM
                RISC *was* science, not religionMichael S04/04/17 01:45 AM
                  RISC *was* science, not religionIreland04/04/17 09:30 AM
                  RISC *was* science, not religiondmcq04/04/17 09:43 AM
              RISC *was* science, not religionDavid Hess04/05/17 02:18 AM
                RISC *was* science, not religionMichael S04/05/17 04:02 AM
            RISC *was* science, not religionDavid Hess04/05/17 01:54 AM
              RISC *was* science, not religionRichardC04/05/17 04:31 AM
                ARM solution and MIPS condition evaluation?Heikki Kultala04/05/17 05:23 AM
                  ARM solution and MIPS condition evaluation?dmcq04/05/17 07:34 AM
                    MIPS condition evaluation?Heikki Kultala04/05/17 08:28 AM
                      MIPS condition evaluation?Michael S04/05/17 10:28 AM
                        MIPS condition evaluation?Heikki Kultala04/05/17 10:55 AM
                          MIPS condition evaluation?Michael S04/05/17 12:12 PM
                            MIPS condition evaluation?Heikki Kultala04/05/17 12:54 PM
                              MIPS condition evaluation?dmcq04/05/17 01:02 PM
                              MIPS condition evaluation?Heikki Kultala04/05/17 01:03 PM
                  ARM solution and MIPS condition evaluation?RichardC04/05/17 09:18 AM
                    ARM solution and MIPS condition evaluation?Linus Torvalds04/05/17 11:20 AM
                      ARM solution and MIPS condition evaluation?RichardC04/05/17 01:23 PM
                        ARM solution and MIPS condition evaluation?Linus Torvalds04/05/17 05:51 PM
                          ARM solution and MIPS condition evaluation?RichardC04/05/17 09:06 PM
                            TransputerRichardC04/06/17 05:20 AM
                            ARM solution and MIPS condition evaluation?Linus Torvalds04/06/17 08:54 AM
                              ARM solution and MIPS condition evaluation?RichardC04/06/17 11:14 AM
                                ARM solution and MIPS condition evaluation?Linus Torvalds04/06/17 11:40 AM
                                  ARM solution and MIPS condition evaluation?RichardC04/06/17 12:01 PM
                                    your theoryRichardC04/06/17 01:49 PM
                                      your theoryLinus Torvalds04/06/17 02:39 PM
                                        your theoryLinus Torvalds04/06/17 03:04 PM
                                          your theoryIreland04/06/17 03:48 PM
                                            Integrators of RISC cpu's interested only in software app salesIreland04/06/17 05:11 PM
                                          cheap machines with GUIsRichardC04/07/17 04:40 AM
                                            compatibility and evolutionary strategyRichardC04/07/17 06:27 AM
                                              68K clones?Michael S04/07/17 06:40 AM
                                                68K clones?Yuhong Bao04/07/17 07:54 AM
                                                Apollo core ...Mark Roulo04/07/17 10:28 AM
                                                68K clones?Ronald Maas04/07/17 06:07 PM
                                                68K clones?Per Hesselgren04/08/17 01:05 AM
                                                  68K clones?Per Hesselgren04/08/17 01:06 AM
                                                    68K clones?Michael S04/08/17 12:10 PM
                                              compatibility and evolutionary strategyIreland04/07/17 09:33 AM
                                              compatibility and evolutionary strategyIreland04/07/17 09:50 AM
                                                high-margin productsRichardC04/07/17 10:16 AM
                                                  high-margin productsIreland04/07/17 02:53 PM
                                                    high-margin productswumpus04/08/17 07:45 PM
                                                      high-margin productsRichardC04/09/17 06:06 AM
                                                        high-margin productsMichael S04/09/17 06:26 AM
                                                          high-margin productsIreland04/09/17 07:13 AM
                                                            high-margin productswumpus04/09/17 10:01 AM
                                                          user-visible ISA's still evolvingRichardC04/09/17 08:09 AM
                                                            user-visible ISA's still evolvingIreland04/09/17 03:08 PM
                                                      Economics and doing a MIPS, SGI or 3dfx startup today . . . Ireland04/09/17 08:08 AM
                                                        Economics and doing a MIPS, SGI or 3dfx startup today . . . bakaneko04/09/17 10:45 AM
                                                          Economics and doing a MIPS, SGI or 3dfx startup today . . . Ireland04/09/17 01:32 PM
                                        your theoryRichardC04/06/17 04:57 PM
                                          your theoryIreland04/06/17 05:29 PM
                                            your theoryIreland04/06/17 05:45 PM
                                          x86 ISA license historyRichardC04/06/17 05:31 PM
                                            x86 ISA license historywumpus04/07/17 07:35 AM
                                              x86 ISA license historyRichardC04/07/17 09:26 AM
                                          370 on 68KMatt Sayler04/06/17 05:38 PM
                                            370 on 68KDavid Hess04/08/17 10:18 AM
                                          your theoryLinus Torvalds04/06/17 07:20 PM
                                            your theoryRichardC04/06/17 08:34 PM
                                              Intel's clone warsRichardC04/06/17 08:42 PM
                                              your theoryIreland04/07/17 09:05 AM
                                            your theoryrwessel04/06/17 10:53 PM
                                            your theorygallier204/07/17 02:13 AM
                                            your theorygallier204/07/17 02:37 AM
                                              your theoryMichael S04/07/17 05:54 AM
                                                your theorygallier204/07/17 09:57 AM
                                              your theoryDavid Hess04/08/17 10:26 AM
                                                your theoryYuhong Bao04/08/17 10:28 AM
                                                your theorygallier204/09/17 05:38 AM
                                                  your theoryMichael S04/09/17 06:08 AM
                                                    your theoryrwessel04/09/17 10:04 AM
                                                      your theoryDavid Hess04/09/17 04:46 PM
                                                        your theoryrwessel04/09/17 08:58 PM
                                                  your theoryDavid Hess04/09/17 04:23 PM
                                                your theoryRichardC04/09/17 08:16 AM
                                                  your theoryDavid Hess04/09/17 04:58 PM
                                            Positive point about 80286Michael S04/07/17 06:31 AM
                                              Positive point about 80286gallier204/07/17 10:00 AM
                                                Positive point about 80286Yuhong Bao04/07/17 02:43 PM
                                                  Positive point about 80286Per Hesselgren04/08/17 01:16 AM
                                                Positive point about 80286David Hess04/08/17 10:49 AM
                                                  Positive point about 80286gallier204/09/17 05:44 AM
                                                    Positive point about 80286Ireland04/09/17 06:35 AM
                                                      Positive point about 80286gallier204/09/17 07:18 AM
                                                        Positive point about 80286Ireland04/09/17 07:30 AM
                                                          Positive point about 80286gallier204/09/17 10:43 AM
                                                            Positive point about 80286David Hess04/09/17 05:19 PM
                                                              Positive point about 80286Ireland04/09/17 05:24 PM
                                                                Positive point about 80286David Hess04/09/17 06:01 PM
                                                                  Positive point about 80286Ireland04/09/17 06:15 PM
                                                              Positive point about 80286 and MotorolaPer Hesselgren04/10/17 12:22 AM
                                                                Positive point about 80286 and MotorolaPer Hesselgren04/10/17 01:01 AM
                                                                  Positive point about 80286 and MotorolaPer Hesselgren04/10/17 01:39 PM
                                                                    Positive point about 80286 and MotorolaPer Hesselgren04/18/17 09:14 AM
                                                              Positive point about 80286gallier204/10/17 12:26 AM
                                                                Positive point about 80286Michael_S04/10/17 03:21 AM
                                                        Positive point about 80286David Hess04/09/17 05:11 PM
                                                          Positive point about 80286gallier204/10/17 01:15 AM
                                                            Positive point about 80286gallier204/10/17 01:20 AM
                                                    Positive point about 80286rwessel04/09/17 10:12 AM
                                                      Positive point about 80286gallier204/09/17 11:38 AM
                                                        Positive point about 80286Ireland04/09/17 12:17 PM
                                                          Positive point about 80286David Hess04/09/17 05:40 PM
                                                            Positive point about 80286Ireland04/09/17 05:48 PM
                                                          Positive point about 80286rwessel04/09/17 11:05 PM
                                                            Positive point about 80286wumpus04/10/17 06:31 AM
                                                              Positive point about 80286rwessel04/10/17 07:37 AM
                                                                Positive point about 80286David Hess04/10/17 09:53 AM
                                                        Positive point about 80286David Hess04/09/17 05:51 PM
                                                          Positive point about 80286wumpus04/11/17 06:41 AM
                                                            Positive point about 80286gallier204/12/17 04:20 AM
                                                          Positive point about 80286Yuhong Bao04/17/17 01:14 AM
                                                            Positive point about 80286David Hess04/17/17 02:37 AM
                                                              Positive point about 80286Joe Hodge04/17/17 06:54 PM
                                                    Positive point about 80286David Hess04/09/17 05:05 PM
                                                      Positive point about 80286Ireland04/09/17 05:13 PM
                                                        Positive point about 80286wumpus04/09/17 05:22 PM
                                                          Positive point about 80286Ireland04/09/17 05:43 PM
                                                            Positive point about 80286Ireland04/09/17 05:59 PM
                                                  Positive point about 80286wumpus04/09/17 05:17 PM
                                                    Positive point about 80286Ireland04/09/17 05:20 PM
                                        your theorydmcq04/07/17 01:04 AM
                                        your theoryGabriele Svelto04/09/17 01:47 PM
                                          your theoryIreland04/09/17 05:53 PM
                                          your theoryrwessel04/09/17 11:24 PM
                                  ARM solution and MIPS condition evaluation?Doug S04/07/17 11:24 AM
                                    ARM solution and MIPS condition evaluation?Linus Torvalds04/07/17 11:50 AM
                                      ARM solution and MIPS condition evaluation?Doug S04/10/17 09:58 PM
                                ARM solution and MIPS condition evaluation?Tim McCaffrey04/06/17 06:32 PM
                          ARM solution and MIPS condition evaluation?Doug S04/05/17 11:58 PM
                            Are you sure about orders of magnitude? (NT)Michael S04/06/17 03:24 AM
                        ARM solution and MIPS condition evaluation?Tim McCaffrey04/06/17 06:21 PM
                      ARM solution and MIPS condition evaluation?somebody04/06/17 09:41 AM
                        ARM solution and MIPS condition evaluation?Linus Torvalds04/06/17 12:01 PM
                          ARM solution and MIPS condition evaluation?Wilco04/06/17 07:17 PM
                            ARM solution and MIPS condition evaluation?Linus Torvalds04/07/17 11:35 AM
                              ARM solution and MIPS condition evaluation?Linus Torvalds04/07/17 12:20 PM
                              ARM solution and MIPS condition evaluation?Exophase04/07/17 01:22 PM
                                ARM solution and MIPS condition evaluation?Linus Torvalds04/08/17 01:32 AM
                                  Software FP vs trap emulationWilco04/08/17 05:20 AM
                                    Software FP vs trap emulationRonald Maas04/08/17 08:45 AM
                                      Software FP vs trap emulationdmcq04/08/17 10:29 AM
                                        Software FP vs trap emulationdmcq04/08/17 10:44 AM
                                          Software FP vs trap emulationWilco04/08/17 05:24 PM
                                        Software FP vs trap emulationLinus Torvalds04/08/17 10:52 AM
                                          Software FP vs trap emulationIreland04/08/17 11:46 AM
                                          Software FP vs trap emulationMichael S04/08/17 01:23 PM
                                            Software FP vs trap emulationLinus Torvalds04/08/17 03:38 PM
                                              Software FP vs trap emulationMichael S04/08/17 04:23 PM
                                          Software FP vs trap emulation@04/08/17 06:17 PM
                                            Software FP vs trap emulationLinus Torvalds04/09/17 08:59 AM
                                              Software FP vs trap emulationIreland04/09/17 09:20 AM
                                                Software FP vs trap emulationIreland04/09/17 09:35 AM
                                                Software FP vs trap emulationrwessel04/09/17 10:27 AM
                                                  Software FP vs trap emulationIreland04/09/17 01:49 PM
                                              Software FP vs trap emulation@04/09/17 11:59 AM
                                    Software FP vs trap emulationMichael S04/08/17 12:46 PM
                                      Software FP vs trap emulationWilco04/08/17 05:01 PM
                                        Software FP vs trap emulationBrett04/08/17 11:30 PM
                                          Software FP vs trap emulationmatthew04/09/17 01:14 AM
                                            Software FP vs trap emulationWilco04/09/17 07:10 AM
                                  Acorn vs DECRichardC04/09/17 08:27 AM
                                  ARM solution and MIPS condition evaluation?Exophase04/09/17 01:02 PM
                                    ARM solution and MIPS condition evaluation?Wilco04/09/17 02:52 PM
                                      ARM solution and MIPS condition evaluation?Exophase04/09/17 06:16 PM
                                        ARM solution and MIPS condition evaluation?Wilco04/10/17 01:40 AM
                                          ARM solution and MIPS condition evaluation?Exophase04/10/17 01:00 PM
                                            ARM solution and MIPS condition evaluation?Wilco04/10/17 04:19 PM
                              ARM solution and MIPS condition evaluation?Ireland04/07/17 05:34 PM
                RISC *was* science, not religionDavid Hess04/06/17 12:24 AM
                  RISC *was* science, not religionIreland04/06/17 09:54 AM
              RISC *was* science, not religionIreland04/05/17 01:23 PM
            CISC religion?wumpus04/08/17 09:49 AM
              CISC religion?Ireland04/08/17 01:24 PM
              CISC religion?Ireland04/08/17 01:39 PM
                Alan Turing Ireland04/08/17 05:31 PM
                  Alan Turing rwessel04/08/17 09:52 PM
                    Alan Turing Ireland04/09/17 05:35 AM
                CISC religion?wumpus04/08/17 07:19 PM
                  narrow vs wide skillsetsRichardC04/08/17 07:42 PM
                  CISC religion?rwessel04/08/17 09:33 PM
                    CISC religion?wumpus04/09/17 05:10 PM
                      CISC religion?David Hess04/09/17 07:56 PM
                        CISC religion?rwessel04/10/17 12:25 AM
              CISC religion?RichardC04/08/17 03:44 PM
                CISC religion?Michael S04/08/17 04:47 PM
                  CISC religion?Michael S04/08/17 04:52 PM
                    CISC religion?Ireland04/08/17 05:16 PM
                      CISC religion?Michael S04/08/17 05:26 PM
                        CISC religion?Ireland04/08/17 05:41 PM
                          CISC religion?wumpus04/08/17 08:04 PM
                            OT - faster RAMMichael S04/09/17 05:26 AM
                          CISC religion?rwessel04/08/17 10:10 PM
                            CISC religion?rwessel04/08/17 10:10 PM
                      gone parallel now ...RichardC04/08/17 07:15 PM
                CISC religion?gallier204/09/17 06:47 AM
                  fascinating link, thanks! (NT)RichardC04/09/17 09:46 AM
                CISC religion?Ricardo B04/10/17 05:55 AM
                  CISC religion?anon04/10/17 09:49 AM
                    CISC religion?Travis04/10/17 11:30 AM
                      CISC religion?Travis04/10/17 11:32 AM
                        CISC religion?anon04/10/17 02:12 PM
                          CISC religion?Travis04/10/17 07:41 PM
                            CISC religion?Michael_S04/11/17 10:44 AM
                      CISC religion?Ricardo B04/10/17 04:01 PM
                        CISC religion?Michael_S04/11/17 10:56 AM
                          CISC religion?Ricardo B04/11/17 01:27 PM
                        CISC religion?Wilco04/11/17 01:45 PM
                          CISC religion?Michael S04/11/17 02:07 PM
                          CISC religion?Ricardo B04/11/17 04:32 PM
                    CISC religion?Ricardo B04/10/17 04:24 PM
                  CISC religion?dmcq04/10/17 02:17 PM
                    CISC religion?Ricardo B04/10/17 05:16 PM
              CISC religion?Seni04/09/17 04:06 AM
                CISC religion?Ireland04/09/17 05:40 AM
                  CISC religion?wumpus04/09/17 10:08 AM
                yes, except ARM and SPARC lacked cacheRichardC04/09/17 05:50 AM
                  yes, except ARM and SPARC lacked cacheSeni04/09/17 06:19 AM
                    yes, except ARM and SPARC lacked cacheRichardC04/09/17 08:47 AM
                      minimal microcodeRichardC04/09/17 09:33 AM
                        minimal microcodeSeni04/09/17 10:02 AM
                          interesting, that makes sense (NT)RichardC04/09/17 02:45 PM
                      yes, except ARM and SPARC lacked cacheanon04/09/17 08:57 PM
                        yes, except ARM and SPARC lacked cacheRichardC04/10/17 06:18 AM
                          yes, except ARM and SPARC lacked cacheSeni04/10/17 03:51 PM
                            yes, except ARM and SPARC lacked cacheWilco04/11/17 02:56 AM
                              yes, except ARM and SPARC lacked cachedmcq04/11/17 03:06 AM
                                no, ARM's 42 rows x 36 bits = 189 bytes (NT)RichardC04/11/17 08:11 AM
                                  no, ARM's 42 rows x 36 bits = 189 bytesdmcq04/12/17 04:42 AM
                              yes, except ARM and SPARC lacked cacheSeni04/11/17 12:27 PM
                                yes, except ARM and SPARC lacked cacherwessel04/11/17 06:02 PM
                                  yes, except ARM and SPARC lacked cacheSeni04/11/17 10:27 PM
                                    yes, except ARM and SPARC lacked cacheRichardC04/12/17 11:06 AM
                                      yes, except ARM and SPARC lacked cacheSeni04/12/17 12:47 PM
                                        yes, except ARM and SPARC lacked cacheWilco04/12/17 01:38 PM
                                        not the normal usageRichardC04/12/17 07:58 PM
                                        yes, except ARM and SPARC lacked cacherwessel04/12/17 09:40 PM
                                    yes, except ARM and SPARC lacked cachedmcq04/12/17 02:19 PM
                                      yes, except ARM and SPARC lacked cacherwessel04/12/17 09:49 PM
                                        yes, except ARM and SPARC lacked cachedmcq04/13/17 03:44 AM
                                    yes, except ARM and SPARC lacked cacheanon04/12/17 08:06 PM
                        yes, except ARM and SPARC lacked cachewumpus04/10/17 06:37 AM
  Apple confirms that they are ditching Imagination within two yearsAnon04/03/17 02:36 AM
    Apple confirms that they are ditching Imagination within two yearsDoug S04/03/17 12:56 PM
      Or Samsung buys them, develops their own GPU, and uses the patents in the next lawsuit (NT)Anon04/03/17 01:26 PM
        Or Samsung buys them, develops their own GPU, and uses the patents in the next lawsuit Michael S04/03/17 02:33 PM
        Or ARM buys them, and gets any money they can from their IP and customersdmcq04/04/17 09:55 AM
  IMGTEC stock has crashed already.VertexMaster04/03/17 05:33 AM
    IMGTEC stock has crashed already.Andreas04/03/17 07:33 AM
      IMGTEC stock has crashed already.Exophase04/03/17 09:43 AM
    IMGTEC stock has crashed already.Doug S04/03/17 12:51 PM
Reply to this Topic
Body: No Text
How do you spell green?