So with the GNU compiler you can use the preprocessor to get a list of the predefined macros:
$ cpp -dM /dev/null
or if you prefer to invoke the preprocessor via gcc itself:
$ gcc -dM -E - < /dev/null
This should give you a list similar like:
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
For Microsoft’s Visual C++ compiler I have only found pages like:
For Intel’s C++ compiler I found the following page with predefined macros.
And I find this interesting page with a lot of different compilers and their predefined macros to identify them and their versions, if any.
Edit: I also found how to do this with Clang:
$ clang -dD -E - < /dev/null
Found some information in two of Intels chipset datasheets about this issue:
The board utilizes 4 GB of addressable system memory. Typically the address space that is allocated for PCI Conventional bus add-in cards, PCI Express configuration space, BIOS (firmware hub), and chipset overhead resides above the top of DRAM (total system memory). On a system that has 4 GB of system memory installed, it is not possible to use all of the installed memory due to system address space being allocated for other system critical functions. These functions include the following:
- BIOS/firmware hub (2 MB)
- Local APIC (19 MB)
- Digital Media Interface (40 MB)
- Front side bus interrupts (17 MB)
- PCI Express configuration space (256 MB)
- MCH base address registers, internal graphics ranges, PCI Express ports (up to 512 MB)
- Memory-mapped I/O that is dynamically allocated for PCI Conventional and PCI Express add-in cards
And the other note:
Memory between 4GB and 4GB minus 512MB will not be accessible for use by the operating system and may be lost to the user, because this area is reserved for BIOS, APIC configuration space, PCI adapter interface, and virtual video memory space. This means that if 4GB of memory is installed, 3.5GB of this memory is usable. The chipset should allow the remapping of unused memory above the 4GB address, but this memory may not be accessible to an operating system that has a 4GB memory limit.
An item over at the Inquirer said that at the E3 they were unofficially informed that Intel is working on getting back into the games graphics market. This was in May.
In July we have the following item over at the Inquirer in which Intel reveals their G965 graphics solution, which is using technology licensed from PowerVR, back then codenamed Eurasia and now known as GSX (Graphics Shader Accelerator). Now furthermore the article tells us that Intel will also start work on using Muse (Media Unified Shading Engine) for its graphics offering. Simplistically compare Muse to what Cell did, cheap cores in a parellel setup thus enabling improved calculations. In this case with multiple GSX cores (due to the Universal Scalable Shader Engine I think, which combines the pixel and vertex shaders into one design) it might even build a multi-pipeline graphics solution. The only funny thing is that Wikipedia’s PowerVR article lists Muse as a mobile solution according to a company presentation. And indeed, when one checks another article at the Inquirer you see that the roadmap indeed introduces Muse and Athena, the first aimed at portable computing, the latter aimed at desktops (introducing programmable shaders). Of course, if the GSX is a SoC design the lower energy consumption and die size (and gate count)
Funnily enough on the Intel site right now there are two job openings (posted end of July and early August) in the United States for a Senior Graphics Software Engineer and Software Engineer 3D Graphics. The first focusing on what seems to be identify from the end-user (including game developers) point of view where the bottlenecks in the hardware design lie. The latter job seems to focus on driver improvements and driver support for OpenGL 2.0 and DirectX 10. Coincedence?
According to a post by Keith Packard on the Linux kernel mailinglist:
This module contains stuff which Intel can’t publish in source form, like Macrovision register stuff and other trade secrets. It’s optional, so if you don’t want to use a binary module, you don’t get to use code written by Intel agents for these features. And, we also haven’t figured out how and when to release this binary blob, so there’s no way you can use it today. The driver remains completely functional in the absense of the binary piece, and in fact has no reduction in functionality from previous driver releases.
So much for that idea eh?
With recent news of AMD acquiring ATI there was some incorrect reporting that AMD would be dropping the ATI brand in favour of tacking Radeon on its own brand name of AMD. According to Ars Technica the name drop was a miscommunication that spread like fire through the blogosphere as well as online news. This is both the advantage and disadvantage of the quick turn-around time of the online media. One would think that serious technical journalists, however, would verify this with AMD and/or ATI themselves before reporting.
In related news Intel revealed a website where they are offering source code for their 965 IGP. And it becomes even more interesting when put into perspective with an article from InfoWorld where it is said that AMD is strongly considering releasing open source at least a part of the ATI graphics drivers. One can only wonder how NVIDIA will react to these developments.
Intel assembly, let me count the ways I loathe thee…