Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:UAC is for idiots (Score 1) 187

by Mr Z (#49456381) Attached to: LG Split Screen Software Compromises System Security

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.

Comment: Re:UAC is for idiots (Score 1) 187

by Mr Z (#49456365) Attached to: LG Split Screen Software Compromises System Security

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.

Comment: Re:Interlacing? WTF? (Score 1) 113

by Mr Z (#49423125) Attached to: Turning the Arduino Uno Into an Apple ][

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.

Comment: I hide Easter Eggs (Score 1) 290

by Mr Z (#49420681) Attached to: Is This the Death of the Easter Egg?

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.

Comment: Re:Not a 6502 (Score 1) 140

by Mr Z (#49402221) Attached to: Building an NES Emulator

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.

Comment: Re:Tell me something new (Score 1) 140

by Mr Z (#49402105) Attached to: Building an NES Emulator

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.

Comment: Re:Good grief... (Score 1) 681

by Mr Z (#49127891) Attached to: Bill Nye Disses "Regular" Software Writers' Science Knowledge

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."

Comment: Re:Good grief... (Score 1) 681

by Mr Z (#49119563) Attached to: Bill Nye Disses "Regular" Software Writers' Science Knowledge

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. ;-)

Comment: Re:Good grief... (Score 1) 681

by Mr Z (#49118739) Attached to: Bill Nye Disses "Regular" Software Writers' Science Knowledge

Actually, it isn't if the compiler can prove that the layout is not visible outside of the compilation unit.

Ok, that's fair. You also need to ensure its memory image isn't visible to, say, a char*. (That pesky char* exemption in the standard that allows you to write memcpy and memmove is no friend to alias analysis.)

For example, if the address of one of these structs is never taken, then the struct never need live in memory even, so its layout is irrelevant. If addresses do get taken but you can find all the uses of those addresses, then yes, you could play games with the layout if it was impossible for the program to notice. That's perhaps a stronger criteria than compilation unit boundary, though.

What's the justification for compilation unit boundary? It seems like you could expose the layout of the struct (and therefore any compiler shenanigans) through other means within a compilation unit. offsetof comes to mind. :-)

My initial gut reaction is that nearly any interesting data structure wouldn't qualify for this optimization. :-) Sounds like your data matches.

It's much more interesting in environments with on-the-fly compilation, because then you can adapt data structures to use.

Cool. That reminds me of an experiment I heard about at HP. They implemented a PA-RISC to PA-RISC dynamic translator that used run-time information to reoptimize the code. The overall speedup (including the cost of the translator) was in the 5% - 10% range. Here's the paper.

Even then, you can do it outside of the compiler (for example, the NeXT implementations of the Objective-C collection classes would switch between a few different internal representations based on the data that you put in them).

I suppose you could do that in C++ with template specialization. In fact, doesn't that happen today in C++11 and later, with movable types vs. copyable types in certain containers? Otherwise you couldn't have vector< unique_ptr< > >. Granted, that specialization is based on a very specific trait, and without it the particular combination wouldn't even work.

In theory, you could also specialize based on, say, sizeof( item ). I suppose that then becomes an ABI issue with the C++ standard library. Bleh.

I have a love-hate relationship with C++. :-)

You do not have mail.

Working...