- You know what BNF is and can write one for your favorite language.
- You understand the statement (0x2B || !0x2B)
- #2 pisses you off because it's an expression, not a statement.
- But #2 bothers you more because any optimizer worth its salt would replace that with the constant value 1.
- The Mach-O link format morally offends you because Apple plugs it as better than PEF.
- You prefer to code in machine language instead of perl because it's more readable.
- You think Bison as a replacement for Yacc is funny (because of the fitting name), and know the difference between the two.
- You parse in your head while writing code in other languages.
- You understand that compilers are just dumb translation beasts and not really magic at all.
- You'd like to pass this on to all your compiler writing friends, but realize that you don't know any other compiler writers. :-P
I'm sure I could come up with others, but I have to get back to writing registration code. Enjoy!
hahahaha. oh yeah.
Actually I did meet a guy at a party last month who had worked on compilers. Now he's over at Microsoft Research...
LoL, the Dark Sideâ„¢ ;-)
I've heard of friend of friends who work on compilers, here in Austin actually. But they're still basically a mythical creature IMHO. :-P
Yeah, the only two people I know that work on compilers either:
a) Wrote this.
b) Commented already.
However, I will be posting a link to this on my blog... mwahahah. *walks over to Aaron's office to distract him with the cool things he did this weekend*
Love it. And hey, see it from the positive side: These days you can be a mythical creature without knights showing up and trying to kill you :-)
Cool stuff Jon!
LoL@Uli -- Yeah, that is a plus.
Btw Uli, that's a very nice site you have! I especially like the talking moose -- made me laugh!
the sick thing is, most assembly language *is* more readable than perl.
I had to hack the Prograph CPX C-Tools code (yacc plus lots of really ugly C), and read several books on compiler theory beforehand. So while I understand your compiler jokes and they are funny, my brain is still too fried to allow me to laugh! ;-)
There's nothing concrete about compiler writer's block.
@Dr Scott -- Ouch! I feel your pain. :-)
@Reid -- lol, bad pun, no biscuit! :-P
You know you're a geek when:
You use your personal blog to respond to comments left by the person the hall.
:)
Eric in Seattle
You know what (compiler) people mean by "the dragon book". You own two or more of them.
Mach-O is faster for OS X common use cases... PEF is dead, long live PEF! PEF is like the vacuum tube of the Mac world: a small, vocal group of people claim it's better, but whenever you see in an application you can only cringe. That said, I do have a pile of tubes on my desk.
PEF was designed before the glory that is position-independent code reached the Mac, and it shows.
Having worked on the Mach-O linker, as well as dabbled with the PEF linker, I can only assume you've never really dug into either format too much. Mach-O is older than I am -- every single "glorious" OS X app has the *exact same loader code* linked into *every single Mach-O* executable? Why? Because the Mach loader does absolutely no work. :: shudders ::
Trust me, PEF is a far superior format from a technology point of view.
The only reasons Mach-O is "better" are that it is native to OS X (NeXT Step's fault) and it supports multiple embedded binaries. In other words: we can compile both PPC and x86 executables and store them in a FAT binary. However thinking about that I realise apple did this with PEF when they moved from 68k to PPC did they not? And even if it can support multiple binaries; who cares? The bundle architecture of an OS X app has already demonstrated it can handle two executables; Classic and OS X; why not just use the same approach?
Are there any benefits of compiling the two binaries together as opposed to having two separate files? Surely the Mach-O format is just jumping one after the other - it can't be any more sophisticated than that can it?
They most certainly did when they made the switch from 68k to PPC. And you're right, the bundle approach is a solution that would work (though perhaps not as elegant on non-"OS X" platforms).
The only benefit I can think of is that having a single file is less work -- you can put one file up on the web and everyone can download it and it'll just work. However, I don't see that happening too much. People whine about the size of our framework -- I imagine they'll complain equally as loud when their app sizes *double* just so that they can support FAT binaries.
BTW, your comment about Mach-O being native to OS X -- so is PEF. It's just a loader format, nothing magical about it. The only thing that's not native is the Classic sandbox. But a Carbon PEF application is just as native as Mach-O.
True, however there is another element which makes them not so 'native': CFM. Every PEF app has to use CFM for linking against shared libraries (including Carbon - which they *need* to run). This means no PEF app is launched directly, the OS checks what kind of app it's dealing with and if it uses CFM, it has to launch it with the LaunchCFMApp wrapper. This is annoying because your app is always running by-proxy which means permissions and all sorts of other nitty gritty issues have an extra layer of confusion. Thanks Apple!
Aaron,
I'm not sure whether the 68k->PPC switch is proof for the ability of PEF to store several architectures. PEF PPC code is stored in the data fork, while 680x0 code on the Mac was stored in 'CODE' resources. So even if PEF supports multiple architectures, they didn't use that feature back then.
OTOH, the 'cfrg' resource type was used to hold a list of containers for PPC apps. Among other things this was used in HyperCard standalones to have the file start with the stack itself. The 'cfrg' resource then told the OS the offset at which the PPC executable code for HyperCard Player started in the file. I'm not sure whether a container can in any way indicate the architecture, but that might be how one could do it with CFM/PEF.
Oh wait: I just found it in the 'cfrg' resource docs: Yes, it has an architecture field, which may be 'pwpc'. I'd guess they *could* have used it for the Intel switch, then...
hahaha, funny article
especially #2,#3 and #10