People from Transmeta told me stories about how their translators were full of special case optimizations to fix horrors they discovered in Microsoft Windows itself.

heh, when Raymond Chen dunks on the MSVC team =)

Arguably more of an optimization, rather than a fix. Looks like un-unrolling a loop, or better, rolling a loop. Or rolling straight line code?

Couldn't they just turn the optimization off for this loop?

> they fixed it during emulation

It means the fix was applied to run during the emulation loop execution, not that the fix was found and applied while the emulation loop was running.

Which would have made it an emulation code escape.

I was just curious and checked The Old New Thing archive... yes I've been reading Raymond Chen's stories for as long as I remember but hey, it's been 23 years of delivering consistently solid stories about Windows.

I was looking through the compiler docs about memory allocation and I found the section about the debug version of the CRT which could fill the allocated memory with a non-zero canary value to help detect uninitialized memory (assuming you weren't calling calloc - which zero-init's allocated memory).

But there wasn't any similar programmatic debugging aid for detecting uninitialized stack memory.

Going further down the rabbit hole, I discovered the _chkstk function.

The MS C compiler would emit a call to _chkstk on function entry to ensure that stack memory had been paged in. But further reading noted that _chkstk was only emitted if the function allocated a lot of stack memory. And there was source code! MS included the assembly language source code for _chkstk in the CRT source code, installed with compiler.

I needed _chkstk to be emitted for every function not only for functions that allocated >= 4KB of stack variables.

Curses, foiled again.

Then, while perusing the list of compiler command line switches, I see "/Ge".

  /Ge (Enable Stack Probes)

  Activates stack probes for every function call that requires storage for local variables.

Ahhhhh! The grey, storm clouds parted and the sun rays bathed shone down on me in their warmth.

I had all the pieces I needed to fill uninitialized stack memory with a non-zero canary value so I could make detection of uninitialized stack variables more reliable.

_stkfil was born

Modifying _chkstk was easy. I needed to write to every byte of stack in a stack page instead of reading only 4 bytes and skipping to the next page of stack.

While I was mucking in the bowels of modifying _chkstk, I added a 4-byte global variable to hold my canary value. Let the app override what value to use.

In debug builds, _stkfil helped find a couple of bugs, but soon all the stray uninited stack vars were gone and the code was forgotten.

Then I read about InitAll in https://www.microsoft.com/en-us/msrc/blog/2020/05/solving-un...

  InitAll - Automatic Initialization

  In addition to the previously mentioned approaches, Microsoft is now using a feature known as InitAll which performs automatic compile-time initialization of stack variables.

  This section documents how Windows is using this technology and the rationale for why.

  Current Windows Settings

  The following types are automatically initialized:

  - Scalars (arrays, pointers, floats)
  - Arrays of pointers
  - Structures (plain-old-data structures)

  The following are not automatically initialized:

  - Volatile variables
  - Arrays of anything other than pointers (i.e. array of int, array of structures, etc.)
  - Classes that are not plain-old-data

  For optimized retail builds, the fill pattern is zero. For floats the fill pattern is 0.0.

  For CHK builds or developer builds (i.e. unoptimized retail builds), the fill pattern is 0xE2. For floats the fill pattern is 1.0.

> All in all, it took this program 256 kilobytes of code to initialize 64 kilobytes of data.

solidity sweating profusely

[dead]