If you stick to the intersection of "documented interface" and "clearly optimized code paths," you're likely OK. But yeah, having an optimization guide as part of the docs would be better, if it also stays up to date with the source. But, as we all know, the only thing that stays up to date with the source is the source itself.

The difference is on my corporate-issue Windows 7 box, even though I'm nominally Administrator, there are things I can't disable / shut off that I could if I were root in UNIX / Linux.

Yep. I've disabled both Flash and PDF plugins, both of which are common attack vectors. I also run AdBlock, as compromised ad servers are a very common attack vector. Net result is that I've hit 'cancel' once on a UAC prompt that I didn't think was justified.

The thing is, even after a stint as a UNIX admin at a university—a hostile environment if there ever was one—and even finding a couple Solaris security holes that lead to root escalation, I still managed to eventually, one day, get a UAC prompt that didn't make sense to me, and so I mashed 'cancel'. I don't even remember what it was, but it points to the fact that you always, always need to be on your guard.

I really dislike the lack of control I feel when using a Windows box. All my personal machines at home are Linux boxes, except one WinXP system I use for specific tasks that require Windows. And on those Linux boxes, I do damn near everything as an unprivileged user. I only sudo to install packages that come from a verified source, such as the latest GCC.

UAC pops up very infrequently for me. The few places it does, I expect it to. I would actually be a little squicked if it didn't.

Given the amount of piggy-back and drive-by malware out there for Windows, I actually kinda like it. Sure, I think I've hit 'Cancel' exactly once on a UAC prompt, but I've never had my Windows box infected with a trojan.

And yes, I consider myself a power-user. Hell, I've been running Linux on my personal machine since '93, and have at least two Solaris patches that I can point to for root exploits I've helped uncover. I architected the security system on an entire family of processors.

I came here to say pretty much exactly what you did. The funky addressing saved a chip. It's pretty widely documented / known.

Yes, the video used opposite bus phases from the CPU (and doubled as refresh counter for the DRAMs), so there were no wait states due to video fetch. But as you point out, that has nothing to do with the Apple ]['s weird video memory map.

I've hidden Easter Eggs in all the Intellivision games I've sold, and in at least one program I've written for internal use at work.

I don't get to touch the software my company sells. At least not the software that would lend itself to Easter eggs.

But for my Intellivision game work, I've hidden a rendition of my face, a modified "hot pepper" version of a menu, entire other games, and dedications to family. I don't intend to stop.

The Atari 2600 uses a 6507, which is a 6502 die in a smaller package—fewer address lines pinned out.

The Ricoh chips in the NES use an exact copy of the 6502 die layout, plopped in a larger chip. Go have a look. You can see the 6502 portion in the lower right hand corner. (Here's the original MOS 6502 for reference.)

When I say exact, I mean darn near exact: They differ by 5 transistors, apparently, representing a surgical excision of decimal mode.

So yes, the part number is technically not 6502. But, that's really a technicality. It's the same layout and everything, packaged in an SoC. The relevant part to the programmer is that they can pull up a 6502 opcode chart / timing chart and start crackin' away and it'll work just as they expect, undocumented opcodes and all.

True, but that was a 6502 core with an integrated I/O port. I'm pretty sure it largely reused the NMOS 6502 datapath, given that all the 6510 variants are compatible, including undocumented opcodes. At least, so claims Wikipedia.

If you read up on the architects, they intended for the zero page to be "like registers," to allow the accumulator architecture to be reasonable to program. Look at all the addressing modes (direct, indirect, indirect-indexed, and indexed-indirect) that leverage the zero page quite heavily, and compare those to the various indexed addressing modes on, say, an x86.

The low cost of zero-page access made those addressing modes practical.

Sure, calculation results always landed in A, and you quite often needed to move A to other places, but direct access to the zero page was very, very cheap. To do math without it would have required additional data registers.

Thank you for the detailed discussion. I don't have a lot to add at this point.

I will say that your comment on virtualized DMA engines is very interesting to me, however.

At a quick look, the XOR trick depends on there being an integral type large enough to hold the pointer type, and if there is it appears to be legal. A strictly conforming implementation apparently might not have a sufficiently large integral type, although I can't imagine anybody writing one.

The XOR trick is inherently implementation dependent, since it requires manipulating a pointer while it's an integer. I think it's fair to assume anyone using it is only using it on a machine with a sufficiently wide integral type.

What's not strictly conforming in my mind is performing any manipulation on the pointer while it's represented as an integer. However, you would be correct to point out that if reinterpret_cast< sufficient_int_type >( pointer ) gives me value X, and regardless of the shenanigans I pull with X, as long as I supply that exact same bit pattern X to reinterpret_cast< orig_ptr_type >( X ) I should get the original pointer back. And if round-tripping a pointer through an int back to a pointer is strictly conforming, then the XOR trick is strictly conforming too.

(At the risk of sounding like I'm shifting goal posts, I do know the C++11 standard tried to get some wording in there to support garbage collectors. I have no idea how that language reads against the XOR trick. I do know the XOR trick would confuse GC by hiding pointers from it though. As for whether GC could ever work out-of-the-box in real, non-trivial C++98 programs that have been around awhile, allow me to show you my deeply skeptical face. You pretty much need a C++11/14 program written in a more modern style.)

In any case, can we both agree that the XOR-pointers trick is a trick best left in the last millennium in most modern systems?

The extra pointer could be legally put into the padding by a sufficiently smart compiler, I believe.

I don't believe structure copies are guaranteed to copy padding.

It's also moot on most systems: If pointers have the strictest alignment of any type on a given platform, there will never be contiguous padding large enough to accommodate a pointer. The only cases I can think of where pointers don't share the strictest alignment are systems with 32 bit pointers, but require 64-bit alignment for double and/or long long. Surprisingly (or maybe not), 32-bit x86 only requires 4 byte alignment for double and long long.

So even if it was legal for the compiler to play games on you within the padding in a POD type, on most commercially viable systems you'll never have the padding you need in a contiguous field.

We're rather far into the "theoretically possible, but with such restrictions that nobody would bother."

I wasn't saying the XOR trick is illegal in C++. (It does, however, rely on implementation defined behavior, so you likely couldn't use it in a strictly-conforming program.)

I was saying that it's illegal for the compiler to undo bad data structures, such as replacing your XORed pointers with proper prev/next pointers. If you have something like this:

struct ugly {
uint64_t prevnext;
};

Where 'prevnext' is the XORed pointer, the compiler isn't allowed to replace it with something more sane like:

struct ugly {
ugly *prev, *next;
};

...or even...

struct ugly {
uint32_t prevnext;
};

...if it figures out you picked an oversized integer for the storage.

TheRaven64 pointed out some cases where it can be legal for the compiler to rearrange / modify bad structures, but the gains tend to be minimal.

As I recall, the C++ standard does put some requirements on structure layout, as least for standard layout PODs:

* Minimum size of 1 for a structure so that each element of an array of empty structures has a distinct address

* Distinct addresses for all non-bitfield members

* Pointer to struct is convertable to pointer to first member and back

* Increasing addresses for members in order of specification

* Optional padding as required between members and at the end of the structure.

* Layout compatibility between identically declared standard-layout structs for their common initial sequence. (That's a mouthful!)

(There may be some others I'm forgetting... That list was off the top of my head.)

If a compiler wanted to rearrange a structure (say, to eliminate or minimize padding, or to eliminate unused members), it'd have to prove that the program didn't rely on any of the guarantees the standard offers that the compiler's otherwise violating. Violations of the standard by the optimizer are legal as long as you don't get caught. ;-)