Michael, Thanks for your post - it was real education for me.
On Thu, Feb 27, 2003 at 09:24:22AM -0500, Michael D. Crawford wrote: > Mac OS X' drivers are written in C++. I don't know whether this includes > the video, but most likely. You've probably heard that OS X is based on > FreeBSD on top of the Mach microkernel. That's the case but it has a > driver architecture all its own. > > A google search for "iokit" will turn up a lot of stuff. Also try > searching for "darwin kernel". > > It is actually written in a subset of C++ called Embedded C++. What > Apple says is that RTTI, templates and exceptions are inappropriate for > use in a real time system. I don't understand why, but some people feel > that way. I think it means that you leave out all the really good stuff > about C++. > > You also don't really get to use constructors, you only have the default > constructor and then you call a regular function to do the real > initialization, so it can return an error code instead of throwing an > exception as a nontrivial constructor might have to sometimes. > > Here's EC++' homepage: http://www.caravan.net/ec2plus/ > > Here's what Bjarne Stroustrup has to say about EC++, I heartily agree > with him: > > http://www.research.att.com/~bs/bs_faq.html#EC++ I didn't knew about EC++. I've read its rationale, and basically they dismiss alot of C++ just because it's "usually not needed for an embeded application", instead of analyzing the potential benefits/counterfits. Overall I don't think embedded C++ is suited for a DRI 3D driver. Templates is something really useful for DRI drivers, as we want specialized version of several functions. For embedded applications, we can either just rely on the card capabilities, or replace the templates by a single generic version of that template which will be slower, but with a smaller memory footprint. Namespaces is really helpful: instead of adding {radeon_,Radeon,RADEON_}* prefix to the names, we can just use a Radeon namespace. Multiple inheritance and virtual inheritance is, IMHO, essential to design reusable objects for the drivers. Without this and no templates, there wouldn't be much difference between were we stand now. RTTI shouldn't be necessary, as the driver should safely cast a base class pointer into a inherited class, e.g., the Radeon driver can be sure that a pointer to a Generic::VertexFormat, is indeed a pointer to a Radeon::VertexFormat, because that's the only kind of vertex formats it deals. Exception could be useful to gracefully exit when things go wrong, but it's the last of our worries, as important is to avoid that things go wrong in the first place. > One nice thing about OS X' IOKit is the way the kernel exposes APIs for > user space access to the hardware. I have used this to write a firewire > driver without the use of any kernel code, and also to write an > application that queries for a bunch of information about the attached > disk drives. > > I hate to say it, but OS X does this by using Microsoft COM. What you do > is supply a globally unique identifier and then it hands you back an > interface that has a bunch of methods defined in it to do what you want. > It's possible to have different versions of the interface for a given > kind of device, for example new features are added to the firewire > interface as OS X is updated. > > OS X is nice to program. However, someone mentioned speed. I am not at > all impressed by the speed of Mac OS X. Note that OS X is compiled with > gcc. I believe that with extensive use of inline functions, the C++ overhead on a DRI driver will disappear and be even faster in a few cases, because it will allow a level of costumization to each particular hardware which nowadays simply isn't possible without changing a lot of code. Regards, José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
