Rugxulo wrote:
On 8/3/10, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
coded in assembler.
Disagree. Instead improve inline routine support.
Inline routines, written in Pascal(!), would generally produce better code than hand-written assembler, because the optimizer can act on them.
GPC has never (that I know of) been meant to be x86-only, so assembly is shunned.
That's also true. (Though it's acceptable when used as an alternative to otherwise portable code, e.g. the GMP library contains assembler optimizations for various platforms.)
In this case, however, it's a no-brainer, since a simple function such as Complex multiplication couldn't be written more efficiently by hand in assembler than what the compiler normally produces, and it takes away optimization opportunities.
Or maybe there really should be an "x86 task force" for GPC to whip up some smaller / faster bits since it really is a popular architecture these days.
I'd suggest they concentrate on the backend (whether GCC, LLVM, ...) then, since this would benefit all languages.
However, speed optimizations are hard, so my personal interest would just be to shrink it.
Actually understanding speed optimization on modern architectures is hard. Many things that were faster on older processors are now slower. Caching, superscalar execution, branch prediction, etc. It's really hard to evaluate even simple assembler code WRT performance -- furthermore it depends on circumstances, such as whether the program is CPU, memory or I/O bound. We're long past the point where producing efficient code has become easier to do for automatic tools (i.e., compilers) than for humans. (Which doesn't mean that all compilers are optimal, there's certainly room for improvement, but again it's hard, and there are diminishing returns ...)
Extended has remained the highest precision f.p. type in Borland Pascal and probably all other Pascals for 15-20 years, while computer speed and memory have improved by orders of magnitude.
But hardware architecture hasn't. The 4, 8 and 10 byte floats are still the only ones supported directly in hardware on the x86. (For other CPUs that may have a 16 byte float, GCC and therefore GPC probably supports it -- can't check right now.)
FPU, MMX, 3dnow!, SSE, AVX ... which to support? I think most people would (probably incorrectly) say that FPU/MMX is deprecated. Gah, I hate modern computing sometimes, always complicating things, never making it easier.
Sure. BTW, AFAIK the GCC backend doesn't support any of these (yet?), don't know about LLVM. So in this case you're on your own. An additional problem is, e.g. FPU and MMX are mutually exclusive (switching is expensive and destroys the state), so a compiler couldn't simply use both without coordination with other parts of the problem. The convention is, of course, that FPU is generally used, and if one wants to use MMX, one has to make sure no floating point code is used at the same time, and do the switch back explicitly.
It is also time for more accurate integers. Borland introduced Int64 10-20 years ago, and it has remained the standard highest accuracy integer type.
So you want similar to "long long long int"?? Actually, GPC by default makes "longint" 64-bit! Which in rare cases can be confusing. ;-)
Why confusing? It's one power of two larger than "Integer".
FORTRAN and even BASIC have had exponentiation forever.
So has Extended Pascal.
You can emulate it with ISO 7185, something like (I think) this: exp(ln(a)*b)
You can emulate, or let's say implement, all of his wishlist features. The desired compiler features would make it more comfortable (templates, function overloading and especially automatic con-/destructors) or efficient (cross-module inlining).
Frank