Tuesday, April 08, 2008

Tecnologic Jump

    Since 1978, we have had the first x86 architecture (8086 CPU), and it kept changing since then. The question is: ¿why don't start a new CPU from scratch with the nowadays aknowledge?

    I can't see the point of keep adding new instructions for that much time. I agree that SSE instructions and similar are really a good idea to have, but nowadays we have several aditions to a standard x86 CPU (SSE, SSE2, SSE3, SSSE3, SSE4, MMX, ...), so maybe it is worth making a new CPU from scratch with those functions built in, and even more. And possibly replacing the x86 paradigm having into account current computering experiences.

    I think it will be good to have a talk with intel, amd, gcc developers, assembler programmers, and so on, to have a really good base for a new starting architecture, instead of keep adding new instructions to a deprecated (in my opinion) CPU type, and if possible, to keep backwards compatibility with x86 (just like AMD did with its x86_64 proccessors).

    Of course, I am not an expert in this materia, but I think that they should simply drop the x86 plattform.. Any opinion to this will be really apreciated.

Tuesday, April 01, 2008

UPCOMING GCC 4.3.0

    For people who thinks that wait is over: you are wrong! As flameeyes said in his blog "GCC 4.3 will be a bloodshed", I agree with that, but this needn't to be bad at all!

    Is true that most of pedantic warnings are now promoted to errors, and it is really fine, as that leads in most of cases to runtime errors. For example redefinition of macros: When a project is large enough, allowing redefinition of macros is not so trivial, because it can lead to misunderstanding of a macro's value along source code.

    Other changes are a bit nonsense, like not including by default c libraries, and so, a lot of programs cannot compile now. But despite the impact it is causing, I think it is good, since it forces programmers to write better code and there are already plenty of patches out there, but still is a headache to solve, both Gentoo side, and upstream side.

    There are, however, a huge issue with <kernel-2.6.24.4 triggered by an GCC's internal change. As gcc is still respecting x86/x86_64 ABI despite that change, the problem comes from upstream, >=gentoo-sources-2.6.25 is marked stable, or at least they include a 2.6.24.4 backport of DF Clearing (as you can see in Gentoo's bug #213811).

    Fortunately, this wouldn't be so bad, as this version of GCC will come with some major features and improvements that makes it worth of installing and testing as soon as possible, what leads one to think that this version will be next Gentoo's stable gcc version. To mention some optimizations: for example the core2 optimization for that kind of processors which are getting more and more common in nowadays user's computers or the inclusion of SSSE3 and SSE4 multimedia CPU instructions, as well as other tons of new features and changes. To see the whole list, see GCC's Changelog.