Don't need to. Their performance was already good. Optimization of an old arch was only necessary to make its performance acceptable, to make it a minimum system requirement. To enlarge the potential market at the time.

To be honest support for the old arch (and WinXP) is being dropped from the next major release of the software. So the original reference C code is going back in to simplify maintenance. The old ASM is no longer needed. The segment of the market it served effectively no longer exists.

It would be fun to redo it for new archs, I enjoy such things, but its not justifiable. I will continue to occasionally compare it against the C code out of curiosity.

Thank goodness we still have assembly language. :-)

Interestingly the k-cup patent expired and many other companies began to produce single serve packs for Keurig coffee makers. This led Keurig to redesign and produce a v2.0 coffee maker and packs, with all new patent protection. The CEO just admitted that this 2.0 plan was a total failure and they lost a ton of money.

Apparently not by compilers.

You don't seem to understand the purpose of writing in assembly language. Its not to optimize for the current state of the art box. It is to get acceptable performance from old legacy boxes. Some assembly in the right spot(s) can make the difference between an old architecture making the cutoff in terms of acceptable performance, of being able to include that segment of the market in your minimum system requirements.

My point is that such optimizations for the sake of the old boxes doesn't necessarily do any harm to the new boxes. That worrying about future architectures is a red herring of sorts.

Think high performance computing too . An entire OS that takes a small fraction of the CPU Cache.

Not really. I have some computational code that I wrote in assembly 4 Pentium architectures ago. Every new architecture I run it against the C implementation, freshly recompiled with a current compiler. The assembly is still faster given all the hardware and compiler improvements. Now the performance improvement is getting much smaller but it is still a win.

The entire OS would occupy about 1/3 of an Intel i7's cache. For ultra-high performance apps that might actually be useful.

Of course that includes user land apps and such so the footprint of the OS itself would probably be far smaller.

Well it is hosting its own web page and running on a Pentium MMX 200. :-)

Its a unit of storage space measurement equivalent to about 30 seconds of music from iTunes.

So its not bloated and it is fast too? Seems appropriate. :-)

It is if they are already busy with more important issues and cases. Its only not a burden if they currently have some free time.

Personally I think its a length thing. If the loops are very short, if all the nesting is simultaneously visible on screen, no scrolling necessary, then it might be OK. It all depends on the complexity of the code too, the logic would also need to be something readily understandable, the partial bailout something natural, not just some optimization trick.

Have I done so, in C/C++ not sure, in assembly probably. :-)

The problem is break one and break all are not the only cases. Perhaps you only want to break some but not all levels of nesting.

In assembly language. :-)