Personally, I don't like this automatic stack-object deletion. I prefer a uniform system: either you don't worry about memory management at all (Java) or you do (Pascal, C). A combination of both only causes confusion imho.
Linking at the procedure level instead of at the unit level is mostly a feature of the compiler. In FPC we fake this more or less by compiling all variables and procedures to seperate objects, put all those objects in a library and then let LD figure out which which objects are needed when linking. The big disadvantages are
you have to create an insane amount of object files for some moderately complex units. Fortunately, we've now got a built-in assembler (based on NASM, but optimized and tweeked) and a library writer which makes up for this.
LD is sloooooooooooooooow when linking against such libraries. That's why we'll start working on an internal linker as well.
Delphi gets the most speed from its internal linking. We already have an internal assembler (adapted from NASM), but no linker yet and LD is very slow. The compiling itself is quite fast.
Is it due large structural changes in gcc, or due low priority of gpc? objective-c, chill and gjc doesn't seem to be affected much.
I think it's the former. It happened when GCC wen from 2.8.x to 2.9.x (I think that's when they switched from GCC to EGCS). Even if the GCC people regard GPC as low priority, that shouldn't matter since GPC has its own programming team.
So it will be windows-only. I got the impression, that you intend to support COM cross-platform.
I don't think so, but I really am not sure (I'm not into Windows nor into Delphi style programming, so I'm not the best person to answer this:)
FPC started out as FPK-Pascal, written by a German student for personal use because he didn't like the fact that Borland wouldn't produce a 32bit Pascal compiler (somewhere in 1995). He looked at GPC, but didn't like it because it was written in C, so he wrote his own compiler in Pascal.
I think the main reaon we stuck to our own code generator in Pascal and didn't switch to gcc is because
it works fine
this is a hobby project of ours and we like tinkering with low level stuff too
we're not dependent on any other project. GPC uses GCC and they sometimes need quite a bit of time to adapt GPC when a new version of GCC comes out
if there is a bug somewhere, it's in our code and it's much easier to debug your own code than someone else's (plus that you don't have to determine in whose code the problem lies).
And how do you want support COM under non-windows oses? Last time I heard, GUIDs in class interface declaration are windows-only-registry-dependent thing
I don't think it's the intention to take COM support cross-platform. If you want cross-platform code, user CORBA. If you want to use things like Direct-X, Active-X etc however, COM support is very handy/necessary.
GTK bindings are included and most example programs have been translated to Pascal as well. We don't have Qt bindings yet, but if Kylix includes them (since Kylix uses Qt by default), you should be able to use them with FPC as well.
Actually, FPC does support operator overloading (but not yet as part of a class definition). Interfaces support is indeed not yet there, but we're working on it/
Since the main site seems to be pretty slashdotted already (and the US isn't even awake yet:), here are the mirror links (I've only added those of which I know for sure they have 1.0):
GNU Pascal and Free Pascal are quite different beasts:
GPC is written in C, FPC is written in Pascal (so Pascal programmers who don't know C can also understand the compiler internals and work on it). Furthermore are the compiler sources a really good test for the compiler itself.
GPC supports ANSI ISO Pascal, Extended Pascal and the Turbo Pascal dialect (they are working on integrating Delphi support too afaik). FPC supports the Turbo and Delphi dialects combined with several extra's (function/procedure/operator overloading for instance). GPC also supports some extra features, but I don't know which by heart.
GPC is built on top of GCC and uses libc, FPC is written from the ground up and has its own Run Time Library. The obvious disadvantage for FPC is that it isn't available for all architectures GCC runs on, the less obvious advantage is that we don't have to worry about any structural changes in GCC (it sometimes takes a few months before GPC is adapted if GCC is updated)
FWIW, you'll find that the optimizer in 1.0 is probably not much better than in the previous version you tried. If you want to try the new optimizer, get an optcomplinux.tar.gz snapshot (from the development section of the website) and use that in conjunction with -OG3p3 or -OG3p3r)
No, we don't assume that inux=ia32/linux. The problem is that the compiler started out as a 80x86 only project. The m68k port was later on done by one person (who almost literally translated the 80x86 codegenerator to generate equivalent m68k instruction), but never maintained afterwards.
Now that version 1.0 is finally out of the door, work continues on at least two versions:
one is pretty much the logical evolution of 1.0: no big structural changes, but lots of extra features like Delphi interfaces support (including COM/CORBA), a much improved optimizer etc.
the other one will include a completely rewritten code generator so it becomes as much processor independent as possible, with initial ports to at least the i386, PowerPC and Alpha (m68k probably too).
The latter has still a loooooooooong way to go though.
We are indeed no (L)GPL specialists, but the modification to the LGPL we've done is that we allow static linking under Dos (because, afaik, you normally are forced to dynamically link against LGPL libraries dso the user can upgrade the libraries seperately from the program). Dynamical linking under Dos is even supported yet afaik...
Since the Free Pascal Compiler can compile (most) Delphi code, you should be able to do all your design etc in Kylix and then compile the result with FPC. Unless some critical information necessary to compile is stored in the project files, that is (but I don't think that's the case).
MPW contains it's own command line-like stuff. I say command line-like because it's more than a simple command line: it's text editing window in which you can select any piece of text and press enter to execute it.
This is very nice, because e.g. the compilers' error messages are actually commands which automatically open the respective source file and highlight the line where the error is.
... it isn't the end of the world (or Bungie for that matter). Read this interview for clarification. Then you'll know that
Bungie remains autonomous inside Microsoft
The decision on which platforms to develop for remains completely with Bungie
the deal with microsoft was signed on a parchment made of human skin with the blood of a virgin goat (well, they're not sure whether the goat was actually virgin, but that's just a small nit)
Actually, GCC optimizes best for 80x86 and iq less good for other architectures. The reason is simple: most OSS people are using 80x86 hardware and as such there's more manpower available for 80x86 development.
Recently, there was a post in a (codewarrior) newgroup from an Apple employee who stated that GCC for PowerPC generates quite slow code (when compared to CodeWarrior, which itself isn't bad, but not great either). However, since Apple is using GCC as main compiler for MacOS X, they have some of their compiler guys working on GCC (and are committing the patches back to Cygnus/FSF/whoever-is-in-charge) so this situation should improve.
The fee is 25c per machine, it's not a per-port fee. And USB2 is completely unsuitable for applications where FireWire is used (such as digital video), because you can't guarantee bandwidth. Also, USB works with hubs where with FireWire every device can be a master/slave (ie. your camcorder can transfer data directly to an external HD without the data passing through your computer)
While I'm sure the author of the article has some points, keep in mind that none of the benchmarks (except maybe the memory bandwidth one) take AltiVec into acount. And before you shout "there are almost no apps that take advantage of it anyway!", think about it that Apple is integrating AltiVec optimizations in about every component of MacOS X: QuickTime, OpenGL, Quartz, sound manager, memory manager etc., which means that every app will benefit of it.
And if you are shocked that Apple's commercials are misleading, it's indeed time to wake up. You didn't really believe that if you drink Fanta(tm), everything suddely becomes fun, right? Apple's claims are no lies (it is quite possible to get 2GFlops of sustained performance), but they're not necessarily relevant to you either (how often do you have to do tons of single precision FPU calculations with an AltiVec optimized application?) As usual, the thruth lies somewhere in the middle...
And personnally, I think that when you buy a Mac, you not only buy it for the raw performance, but because of (and some of the following may or may not apply to you) the OS, the GUI, the casing, Steve Jobs' showmaker capabilities, the fact that most people have a PC, the fact that you want to run most "common/known" software titles without needing Windows (well, there's always WINE under Linux of course),... Whatever.
Backside cache = L2, not L3 (Macs never had L3 cache; you can only get it if you plug a G3/G4 upgreade board in a pre-G3 Mac, in which case your old L2 cache becomes L3). In the G4 systems, it sits on its own dedicated 128bit bus (since AltiVec loads are 128bit), so it's plenty fast.
The current bus bottleneck on the Macs is not memory->CPU (in part because of the large cache, in part because the G4 uses the new MaxBus protocol instead of the old MPC (or was it MPX?) one), but memory/cpu -> video. The reason is that Macs don't have something equivalent to Intel's store gathering. The AltiVec streaming hints slightly remedy this, but on the whole Intel's technique provides for better performance.
The "certain [AltiVec] instructions may have been better optimized than others" comment is mere speculation on your part. Wrong specualtion actually: pretty much all AltiVec instructions take 1 cycle. Afaik only the permute-class instructions (which MMX/SSE doesn't have) take longer (and maybe some FPU related ones, like getting an estimate for the reciprocal).
If your biggest complaint is that AltiVec mayt be overkill in terms of spilling transistors, then better start complaining about the PII/PIII/Athlon etc. Because they're based on the severely outdated IA32 architecture, they're full of hacks to overcome performance limitations (from translating the CISC instructions to RISC ones to insanely deep pipelines that obviously cause huge penalties in case of branch misses, which in turn requires huge branch prediction logic support). The G4 consists of 10.5 million transistors (including the 2 (!) AltiVec cores). That's less than half of the Athlon's 22 million transistors.
If you think it's overkill in terms of functianality, than what exactly could be easily left away? Use only 64bit registers instead of 128bit ones? I don't think so: most matrices used in 3D maths are 4x4, so one row = 4 x single precision value = 4x32bits = 128bits. On the instruction front I think the only ones which may be a little superfuous are some bit packing/reordering ones, though I can imagine they can come in very handy when processing sound, (de)compressing video/sound data or when doing color conversions (not everyone plays games). Dit you actually look at the AltiVec instruction set?
Yes, ATi's drivers have been improved. They improve constantly actually, almost every month another.001 release is done in one way or another The day you posted your reply, another one was done, which again improved performance. I think this pretty much shows that ATi isn't really quick optimizing their drivers for the Mac... If you want frame rates, check here
Of course, you can always flame me for not previewing what I typed... BTW: Mac graphics drivers (especially those of ATi) are NOT as optimized for the Mac as for the PC. Even John Carmack complains about this all time.
Altivec is designed for DSP usage but many apps demonstrate its potential as a desktop SIMD
Such as?
Photoshop, SoundJam (MP3 encoding), Quicktime (compressing/playing back movies), acceleration of OpenGL (and as such all apps that use it), acceleration of large memory move operations (used within the system's memory manager). But I guess those don't count.
On this measure, the Mac's inferior memory bus loses to that of any modern x86 system--and thus the SIMD performs better, despite being slower under theoretical conditions which would never occur. A mismatch between system thoroughput and processor needs is bad engineering, not good. Of course, since Apple has very little input in the PPC design process, they can't do too much about it, can they?
Check this test. Yes, that test is a bit outdated (since the Macs now use G4's and the PC's PIII/1GHz), but it shows that a G3/400MHz is somewhat faster than a PIII/500MHz, even when when including filters optimized for SSE in the mix: 148 vs 165 seconds. A G3/533 (overclocked) needs only 117 seconds. The Ars Technica article you refer to only tests two filters (both SSE optimized), which isn't a full/fair comparison IMHO
I believe PC's still win in terms of bus throughput (though not by an as large margin as they used to). Most of this is made up for by the large backside cache of the PPC's (1MB of cache running at half the processor speed on a dedicated bus).
In any case, it's well known that Photoshop is better optimized for the Mac than the PC, simply because most Photoshop users are on Macintosh. (Another good feature of the Mac--better color management. That makes 4.) Thus, Photoshop is written first for the Mac and then ported to the PC. Similarly, AppleWorks is written first for the Mac and (was) then ported to the PC: it too runs faster on a Mac. Also similarly, MS Word is written first for the PC and then ported to the Mac. It runs several times faster on a PC. Just as MS Word is an unfair benchmark, so too is Photoshop
Photoshop is just as much optimized on the PC as on the Mac. Want proof? One of the first applications that supported MMX and SSE when they first arrived, was.... Photoshop!
I don't think you can compare the porting of Word and/or AppleWorks with that of Photoshop, because the latter is a very CPU intensive program and the former are not. Scrolling speed of Word processors depends more on the typematic delay/rate and the speed of your video card/drivers than on your CPU speed. Also, MS Word on the Mac uses several "Windows compatibility libraries" so they can use the same API for the functionality. Maybe Photoshop does the reverse on Winodws, but the speed of Photoshop filters isn't determined by the speed of the UI or system calls.
[AltiVec] Yes it does. It may end up being applied usefully to certain desktop applications, but a chip is always best at the niche it was designed for. In the case of the PPC, that niche is not the desktop, and it shows.
AltiVec is (almost?) a complete superset of MMX and SSE. Both of those were designed for desktop machines.
You've got a point there! You're correct the reasoning in my original reply may have been wrong (I suppose like yyou said the rest of the OS will be quite system independent, though I don't know for sure either), but even then the 80x86 port of Darwin doesn't run on just any 80x86 box.
Apple simply doesn't have the resources to write drivers for every chipset out there (they even don't support all PCI PowerMacs in the PPC build, such as those based on the catalyst motherboard).
Then again, this is where the OpenSource community is supposed to kick in if they want Darwin running on their box (itches and scratching et al). But even once it is technically possible to compile/run MacOS X on Intel hardware, you'll still have to convince Apple that it would be a good thing for them to release it.
Slashdot Mirror
Linking at the procedure level instead of at the unit level is mostly a feature of the compiler. In FPC we fake this more or less by compiling all variables and procedures to seperate objects, put all those objects in a library and then let LD figure out which which objects are needed when linking. The big disadvantages are
--
Delphi gets the most speed from its internal linking. We already have an internal assembler (adapted from NASM), but no linker yet and LD is very slow. The compiling itself is quite fast.
--
--
I think the main reaon we stuck to our own code generator in Pascal and didn't switch to gcc is because
I don't think it's the intention to take COM support cross-platform. If you want cross-platform code, user CORBA. If you want to use things like Direct-X, Active-X etc however, COM support is very handy/necessary.
--
GTK bindings are included and most example programs have been translated to Pascal as well. We don't have Qt bindings yet, but if Kylix includes them (since Kylix uses Qt by default), you should be able to use them with FPC as well.
--
Actually, FPC does support operator overloading (but not yet as part of a class definition). Interfaces support is indeed not yet there, but we're working on it/
--
--
--
FWIW, you'll find that the optimizer in 1.0 is probably not much better than in the previous version you tried. If you want to try the new optimizer, get an optcomplinux.tar.gz snapshot (from the development section of the website) and use that in conjunction with -OG3p3 or -OG3p3r)
--
Now that version 1.0 is finally out of the door, work continues on at least two versions:
- one is pretty much the logical evolution of 1.0: no big structural changes, but lots of extra features like Delphi interfaces support (including COM/CORBA), a much improved optimizer etc.
- the other one will include a completely rewritten code generator so it becomes as much processor independent as possible, with initial ports to at least the i386, PowerPC and Alpha (m68k probably too).
The latter has still a loooooooooong way to go though.--
We are indeed no (L)GPL specialists, but the modification to the LGPL we've done is that we allow static linking under Dos (because, afaik, you normally are forced to dynamically link against LGPL libraries dso the user can upgrade the libraries seperately from the program). Dynamical linking under Dos is even supported yet afaik...
--
Since the Free Pascal Compiler can compile (most) Delphi code, you should be able to do all your design etc in Kylix and then compile the result with FPC. Unless some critical information necessary to compile is stored in the project files, that is (but I don't think that's the case).
--
This is very nice, because e.g. the compilers' error messages are actually commands which automatically open the respective source file and highlight the line where the error is.
--
Bungie doesn't have to port Halo to the Mac, they alsways do simultanous development on at least Mac and Windows of their titles.
--
... it isn't the end of the world (or Bungie for that matter). Read this interview for clarification. Then you'll know that
--
--
Recently, there was a post in a (codewarrior) newgroup from an Apple employee who stated that GCC for PowerPC generates quite slow code (when compared to CodeWarrior, which itself isn't bad, but not great either). However, since Apple is using GCC as main compiler for MacOS X, they have some of their compiler guys working on GCC (and are committing the patches back to Cygnus/FSF/whoever-is-in-charge) so this situation should improve.
--
The fee is 25c per machine, it's not a per-port fee. And USB2 is completely unsuitable for applications where FireWire is used (such as digital video), because you can't guarantee bandwidth. Also, USB works with hubs where with FireWire every device can be a master/slave (ie. your camcorder can transfer data directly to an external HD without the data passing through your computer)
--
And if you are shocked that Apple's commercials are misleading, it's indeed time to wake up. You didn't really believe that if you drink Fanta(tm), everything suddely becomes fun, right? Apple's claims are no lies (it is quite possible to get 2GFlops of sustained performance), but they're not necessarily relevant to you either (how often do you have to do tons of single precision FPU calculations with an AltiVec optimized application?) As usual, the thruth lies somewhere in the middle...
And personnally, I think that when you buy a Mac, you not only buy it for the raw performance, but because of (and some of the following may or may not apply to you) the OS, the GUI, the casing, Steve Jobs' showmaker capabilities, the fact that most people have a PC, the fact that you want to run most "common/known" software titles without needing Windows (well, there's always WINE under Linux of course), ... Whatever.
--
--
Of course, you can always flame me for not previewing what I typed...
BTW: Mac graphics drivers (especially those of ATi) are NOT as optimized for the Mac as for the PC. Even John Carmack complains about this all time.
--
If you want a result for a G4, see . That's PSBench 5.5 instead of 5.0 though, so you can't compare those numbers with the previous (it's also a G4 upgraded system, not one using Apple's Sawthooth motherboard). I don't know a site where they have PSBench 5.5 PC scores. On this same page you can also see the memory throughput has improved significantly with the G4 (and that's only a G4 processor in an older system, memory throughput on current Apple systems is higher than that since they have a better bus).
I believe PC's still win in terms of bus throughput (though not by an as large margin as they used to). Most of this is made up for by the large backside cache of the PPC's (1MB of cache running at half the processor speed on a dedicated bus).
--
Apple simply doesn't have the resources to write drivers for every chipset out there (they even don't support all PCI PowerMacs in the PPC build, such as those based on the catalyst motherboard).
Then again, this is where the OpenSource community is supposed to kick in if they want Darwin running on their box (itches and scratching et al). But even once it is technically possible to compile/run MacOS X on Intel hardware, you'll still have to convince Apple that it would be a good thing for them to release it.
--
See Dandy's answer to your original post, he's saying exactly what I meant.
--
N O
It makes it more feasable to do the port, but MacOS X is much more than Darwin.
--