I honestly don't know. Currently, it's not really a future task anymore, it's a task that's already well underway. The parts of the code generator that are already completely processor independent and for which the powerpc support is already implemented (ppc implementations not tested yet though), are

* basic flow control structures (while..do/repeat..until, for..do, goto/label, if..then..else, exit, break, continue)
* type conversions (all)
* constant handling (all)
* some memory handling related stuff (loadvmtnode, new/dispose, address-operator, dereferencing pointer, record subscript, self, with..do)
* most things which require compiler magic (read(ln)/write(ln), str, val, rewrite)
* 64bit arithmetics on 32bit processors
* most string operations
* most set operations

The parts of the code generator that are generic, are also already tested because every time something like that was implemented, the i386-specific code was removed at the same time.

In addition, most powerpc-specific RTL routines are already finished (some of them also tested).

So what's still left to do?

Compiler:
* handling of calls and parameters
* basic mathematical operations (add/sub/mul/xor/or/not and comparisons on ordinals and/or enumeration types)
* shr/shl for ordinal types
* div/mod for ordinal types
* "load" nodes (load a global/local variable, load a parameter, load a variable from a shared library etc)
* assignments (put the result of an expression in its destination)
* function result handling
* creation of "array of const" parameters
* handling of interfaces etc
* handling of case..of, .. in ..
* handling of array indexes
* lots of small helper routines for the code generator

RTL:
* finish ppc specific things and test them
* create at least a system and "dos" (= unit containing basic file access routines) units for the OS'es you want to support

For those of you listed as working on the Mac port (Jonas Maebe, Florian Klaempfl, Robert Dell, and Casey Duncan), can I get a status update from each of you?

Currently, I'm not doing very much for the compiler because I have a lot of work for the university, but during the vacation and at the start of the school year, I did pretty much everything listed in the "already done" section above.

Let me know the last thing you worked on, and give me your perspective as to where this Mac port is headed (feel free to tell me "into the toilet" if that's what you really believe). I think it would be a shame if the Mac is left behind on this one.

For starters, I think Mac OS X will be a lot easier than Mac OS 9.x and below because of the unix underpinnings. However, we try to keep everything as generic as possible in every way nowadays and I still intend to create both a "classic" Mac OS and Mac OS X version. Debugging of the code generator will mostly happen under Mac OS X though for obvious reasons :)

Jonas

you wrote

Compiler: * handling of calls and parameters * function result handling

This is the job for you, Jonas :)

* "load" nodes (load a global/local variable, load a parameter, load a

variable from a shared library etc)

* assignments (put the result of an expression in its destination)

I implemented already parts of it but I don't know if I commited it ..

Recently, I tried to compiler the PowerPC compiler but it fails.

I haven't had the courage to look at them yet though :/

Yes, they're in the compiler/new directory. But they need to be updated probably because since that time several things have been changed to those units.

Recently, I tried to compiler the PowerPC compiler but it fails.

That's quite logical since I haven't tried to compile most things yet :)

Jonas

Hi,

two questions:

* Is there a plan, when 64-Bit support will be finished (IA64 and especially AMD hammer's)?

* Is there a limit for usable memory for freepascal (1.0.*) programs (except the 4GB limit of course)? (I ask because I'm not sure whether all address arithmetic is unsigned.)

Best regards,
Stefan

* Is there a limit for usable memory for freepascal (1.0.*) programs (except the 4GB limit of course)? (I ask because I'm not sure whether all address arithmetic is unsigned.)

You will get troubles anyway if address arithmetic is wrong:

- on linux the stack is often above the 0x80000000, I think (but I am not sure anymore) that on FreeBSD also the .text section is loaded above the 0x80000000 value...

- windows also (at least win95) does use addresses above 0x80000000 for system DLLs.

So any error in using signed operation could
already break small program...

No. The AMD hammer support even hasn't started :/ though it shouldn't that hard ...

I really don't know if it is worth to support both architectures (and we don't have so
much time to support everything :/ ). I can't believe that (on the long run) both will survive.

I still think that the ia64 is a really good architecture for the next 20 years, so ...

Pierre Muller wrote

You will get troubles anyway if address arithmetic is wrong: - on linux the stack is often above the 0x80000000,

Yes, it depends on the kernel (settings). (Here stack starts/ends at $C0000000 )

So any error in using signed operation could already break small program...

What I mean with "address arithemtic" is this:

var i    : longint;
    m,l  : ^longint;
begin
...
i:=1234;
m[i]:=l[i*6+5678];
end.

It's not possible to control how "i*6+5678" is calculated. The compiler translates this example to:

movl $1234,_I
movl _M,%eax
movl _I,%edx
movl _L,%ebx
movl _I,%ecx
imull $6,%ecx
addl $5678,%ecx
movl (%ebx,%ecx,4),%edi
movl %edi,(%eax,%edx,4)

That means integer multiply. But in this case signed and unsigned multiply should be the same ("mul reg,mem" does not exist).

So in this example it should be possible to access more then 2GB.

Best regards,
Stefan

Florian Klaempfl wrote

I still think that the ia64 is a really good architecture for the next 20 years, so ...

... for expensive servers and supercomputers (unlike the AMD hammers). I think the IA64 architecture will replace architectures like the HP PA-RISC's (PA8500, PA8600, PA8700 ...) and Alpha family.

Best regards,
Stefan

Sure it's possible to control it. If you declare "i" as cardinal, the whole expression will be calculated in cardinal.

Jonas

From: "Florian Klaempfl"

We'll see. Do not underestimate installed base if x86 applications. IA64 implementations are very, very bad at executing x86 code. x86-64 is naural extension, there should be no performance penalty for legacy code. And adding support to the stuff should be ways easier (esp. in 32bit adressing mode with 64bit registers).

I still think that the ia64 is a really good architecture for the next 20 years, so ...

There are serius issues about this stuff. To sum that up: the innards of the CPU are very complex, and this design does not lend itself easily anything like dynamic execution. With new techniques like on chip SMT (Symmetric multi threading) with shared resources and other - OoO - used by the majority of top performing architectures (Alpha, PA RISC, both x86 current incarnations, Power PC and last but certailly not least new Power from IBM) it does not yield best promise from IA64. BTW -- the design of the thing has started back in 1994 before ANY dynamic execution CPU was released -- the outcome was then unknown, and complexity of the dynamic execution seemed to be bottleneck in the future. Now it apeared that complexity of OoO is not that bad, classic VLIW never went out of signal processing niche (with the rather failed exception of Transmeta) and VLIW boosted to apropriate performance (IA64) is more complex inside than OoO chips. Adding SMT or even worse DMT (Speculative threads) would raise the complexity, size and power draw to unseen levels.

So don't put your bets yet.

More of this stuff shows sometimes on hardware architecture newsgrouops and Web BBs...

rgds
Sebastian Kaliszewski

From: "Florian Klaempfl"

We'll see. Do not underestimate installed base if x86 applications. IA64 implementations are very, very bad at executing x86 code. x86-64 is naural extension, there should be no performance penalty for legacy code. And adding support to the stuff should be ways easier (esp. in 32bit adressing mode with 64bit registers).

I still think that the ia64 is a really good architecture for the next 20 years, so ...

There are serius issues about this stuff. To sum that up: the innards of the CPU are very complex, and this design does not lend itself easily anything like dynamic execution. With new techniques like on chip SMT (Symmetric multi threading) with shared resources and other - OoO - used by the majority of top performing architectures (Alpha, PA RISC, both x86 current incarnations, Power PC and last but certailly not least new Power from IBM) it does not yield best promise from IA64. BTW -- the design of the thing has started back in 1994 before ANY dynamic execution CPU was released -- the outcome was then unknown, and complexity of the dynamic execution seemed to be bottleneck in the future. Now it apeared that complexity of OoO is not that bad, classic VLIW never went out of signal processing niche (with the rather failed exception of Transmeta) and VLIW boosted to apropriate performance (IA64) is more complex inside than OoO chips. Adding SMT or even worse DMT (Speculative threads) would raise the complexity, size and power draw to unseen levels.

So don't put your bets yet.

More of this stuff shows sometimes on hardware architecture newsgrouops and Web BBs...

rgds
Sebastian Kaliszewski

At 13:24 27.11.01 +0100, you wrote:
[...]

So don't put your bets yet. More of this stuff shows sometimes on hardware architecture newsgrouops and Web BBs...

I know all this discussions but here I see the iA64 from the view of the compiler designer :) and here the iA64 is brilliant. But I don't think that the iA64 will be important the next years, but it will get interesting when the transistor count of processors reaches 10^9 to 10^10. Having SMT _and_ the variable VLIW concept of the iA64 will be probably the only the solution to use a lot of execution units ...

Regarding x86-64: It sounds interesting but I can't believe that AMD has the power to introduce it into the market. 3DNow wasn't a success either and is dead though it was much more compatible with existing architectures than x86-64
will be and for certain applications it was very promising.

What I suspect what happens is if the x86-64
gets too big and the iA64 fails Intels extend the x86 architecture as well to 64 bit
(of course in an AMD incompatible way) with some "reused" iA64 concepts (references:
3DNow<->SSE and the i860/i486 story :) )

Keep the size of Intel and AMD in mind when discuss this issues!!

Maybe I forgot one point to mention: the x86-64 architecture is probably the easiest way to get the compiler 64 bit

From: "Florian Klaempfl"

I know all this discussions but here I see the iA64 from the view of the compiler designer :) and here the iA64 is brilliant. But I don't

think

that the iA64 will be important the next years, but it will get

interesting

when the transistor count of processors reaches 10^9 to 10^10. Having SMT

_and_

the variable VLIW concept of the iA64 will be probably the only the

solution

to use a lot of execution units ...

With SMT (the one with shared resources) and especially DMT (speculative threads) you could as well forget about VLIW at all (its an unneeded baggage then). Anyway the problem will be not the number of transistors available but designing CPU of such enormous dimensions. Processor designers will run into funny problems with the amounts of transistors -- there might be just too many transistors to use them as single CPU logic. Designing 20 isuue CPU is hard not because of OoO logic (or lack of it) but by the sheer problem of effectively dispatching and *sharing* data between all the execution units (40 port regsiter file of 128 64bit registers would be incredible monster, thats why such desings like Alpha EV6 are duplicating the register file, and introduce delays when data has to be forwared between parts of CPU attache to diferent register files -- but doing such stuff on inorder design raises complexity to incredible amounts, and moving IA64 into OoO design is simply funny thing -- the result would be a mosnster of vast proportions, VLIW would be then unneeded baggabe left for backwards compatibility and increasing complexity in the hard way.)

Maybe this amounts of transistor will be used as RAM on chip (EDRAM). Scaling into bigger arrays of CPUs requires localising RAM, and NUMA designs (Sun, EV7, Power4, Hammer) the next logical step would be to put ram on chip as well and if you need more ram you just put more CPUs into the package -- speed gain is big as guys from embeded space and some GPU design ares say (having 1024bit bus is not a problem then, and acces latency is reduced 5-10 fold (now moving dram controller on CPU itself promises 2-fold latency reduction (EV7, Power4, Hammer).

Regarding x86-64: It sounds interesting but I can't believe that AMD has the power to introduce it into the market.

Waht do you mean? The chips will be there in about one year time unless some disaster happens, they will perform well in IA32 bit code, treat x86-64 as added bonus which first will be utilised by Linux crowd (since Linux is built from the sources, kernel support, at least for mixed mode is easy to implement so it'll be there)

3DNow wasn't a success either and is dead

I would'nt consider it dead. It has specific purpose of accelerating games, and it was used be quite a number of games and all top videocard drivers (otherwiese Athlon would not be so good for gaming). It was of little use for compiled code (SSE is not much better there, SSE II is the way to go). Comparing initial acceptance of 3D-Now! and SSE the former enyoed better one (no wonder -- Games are mainly for home market and then proportions of Intel and AMD are oscilating around 50-50 for few years. Business market is the Intel's stronghold, so thats why total proportions are now around 78-22 other player are rather unimportant, oscilating around 1% of the market).

Since FPC is rather for home market you (designers) should really consider the ballance for this part of PC world. AMD is much bigger here!

though it was much more compatible with existing architectures than x86-64 will be and for certain applications it was very promising.

And it were used there quite alot. Now, since AMD added SSE, and is going to use (extended to 16 regs) SSE II, bnalance shifts quickly to SSE, of course.

First of all any such move requires time, a lot of time. Design cycle of new general purpose CPU microarchitecture is allmost never shorter than 3 years (K7 is a noble exception but it was certainly death march project, extremely well executed and based on very high motivation -- it was survive or die thing for AMD, if it was 6 months late AMD would be probably bankrupt (they were awfully close to taht, then)). Recent Intel's design cycles are 5 (PIV) and 6-7 years (Itanium). The explicitly stated that the succsor of the NetBurst microarchitecture won't come in earlier than 5 years after PIV. So it won't -- projects of that size are never accelerated, they are rather slipping, often as badly as Itanium (first it was expected in 1997, then 1998, then 1999, then 2000, now it is 2001 and it is "pilot release"), sometimes they are cancelled (EV8). Eventual failure of IA64 won't be realised earlier than in 2005, so any counteraction wont come earlier than in 2007 probably. So it is about 4 years lead for x86-64 before any incompatible 64bit extension comes. Anyway who knows how this market will look by 2007?

Keep the size of Intel and AMD in mind when discuss this issues!!

Of course! But sheer size is not a guarantee of sucess, and power balance often shifts in this market. Intel in many ways looks like IBM at the middle of eighties (Moving slower and slower, bulkier than ever and arrogant as only could be -- well there are lately signs of some reasonable behaviour lately, but they are still weak). What was DELL, Compaq or HP 16 years ago. IBM was unable to regain it's possition from taht time up to date! Other examples of such shits are in GPU market. Compare NVidia and 3DFx from 1998 (it's only 3 years), now where is 3DFx? (bought out be NVidia).

And were are here in the niche market, not majority, and here AMD has much stronger representation than in overall picture. Anyway, why are you supporting Linux or OS/2? Windows has 90% of the market (it's significantly greater dominance that Intels in PC CPU business)? :)

rgds
Sebastian Kaliszewski

From: "Florian Klaempfl"

I know all this discussions but here I see the iA64 from the view of the compiler designer :) and here the iA64 is brilliant. But I don't

think

that the iA64 will be important the next years, but it will get

interesting

when the transistor count of processors reaches 10^9 to 10^10. Having SMT

_and_

the variable VLIW concept of the iA64 will be probably the only the

solution

to use a lot of execution units ...

With SMT (the one with shared resources) and especially DMT (speculative threads) you could as well forget about VLIW at all (its an unneeded baggage then). Anyway the problem will be not the number of transistors available but designing CPU of such enormous dimensions. Processor designers will run into funny problems with the amounts of transistors -- there might be just too many transistors to use them as single CPU logic. Designing 20 isuue CPU is hard not because of OoO logic (or lack of it) but by the sheer problem of effectively dispatching and *sharing* data between all the execution units (40 port regsiter file of 128 64bit registers would be incredible monster, thats why such desings like Alpha EV6 are duplicating the register file, and introduce delays when data has to be forwared between parts of CPU attache to diferent register files -- but doing such stuff on inorder design raises complexity to incredible amounts, and moving IA64 into OoO design is simply funny thing -- the result would be a mosnster of vast proportions, VLIW would be then unneeded baggabe left for backwards compatibility and increasing complexity in the hard way.)

Maybe this amounts of transistor will be used as RAM on chip (EDRAM). Scaling into bigger arrays of CPUs requires localising RAM, and NUMA designs (Sun, EV7, Power4, Hammer) the next logical step would be to put ram on chip as well and if you need more ram you just put more CPUs into the package -- speed gain is big as guys from embeded space and some GPU design ares say (having 1024bit bus is not a problem then, and acces latency is reduced 5-10 fold (now moving dram controller on CPU itself promises 2-fold latency reduction (EV7, Power4, Hammer).

Regarding x86-64: It sounds interesting but I can't believe that AMD has the power to introduce it into the market.

Waht do you mean? The chips will be there in about one year time unless some disaster happens, they will perform well in IA32 bit code, treat x86-64 as added bonus which first will be utilised by Linux crowd (since Linux is built from the sources, kernel support, at least for mixed mode is easy to implement so it'll be there)

3DNow wasn't a success either and is dead

I would'nt consider it dead. It has specific purpose of accelerating games, and it was used be quite a number of games and all top videocard drivers (otherwiese Athlon would not be so good for gaming). It was of little use for compiled code (SSE is not much better there, SSE II is the way to go). Comparing initial acceptance of 3D-Now! and SSE the former enyoed better one (no wonder -- Games are mainly for home market and then proportions of Intel and AMD are oscilating around 50-50 for few years. Business market is the Intel's stronghold, so thats why total proportions are now around 78-22 other player are rather unimportant, oscilating around 1% of the market).

Since FPC is rather for home market you (designers) should really consider the ballance for this part of PC world. AMD is much bigger here!

though it was much more compatible with existing architectures than x86-64 will be and for certain applications it was very promising.

And it were used there quite alot. Now, since AMD added SSE, and is going to use (extended to 16 regs) SSE II, bnalance shifts quickly to SSE, of course.

First of all any such move requires time, a lot of time. Design cycle of new general purpose CPU microarchitecture is allmost never shorter than 3 years (K7 is a noble exception but it was certainly death march project, extremely well executed and based on very high motivation -- it was survive or die thing for AMD, if it was 6 months late AMD would be probably bankrupt (they were awfully close to taht, then)). Recent Intel's design cycles are 5 (PIV) and 6-7 years (Itanium). The explicitly stated that the succsor of the NetBurst microarchitecture won't come in earlier than 5 years after PIV. So it won't -- projects of that size are never accelerated, they are rather slipping, often as badly as Itanium (first it was expected in 1997, then 1998, then 1999, then 2000, now it is 2001 and it is "pilot release"), sometimes they are cancelled (EV8). Eventual failure of IA64 won't be realised earlier than in 2005, so any counteraction wont come earlier than in 2007 probably. So it is about 4 years lead for x86-64 before any incompatible 64bit extension comes. Anyway who knows how this market will look by 2007?

Keep the size of Intel and AMD in mind when discuss this issues!!

Of course! But sheer size is not a guarantee of sucess, and power balance often shifts in this market. Intel in many ways looks like IBM at the middle of eighties (Moving slower and slower, bulkier than ever and arrogant as only could be -- well there are lately signs of some reasonable behaviour lately, but they are still weak). What was DELL, Compaq or HP 16 years ago. IBM was unable to regain it's possition from taht time up to date! Other examples of such shits are in GPU market. Compare NVidia and 3DFx from 1998 (it's only 3 years), now where is 3DFx? (bought out be NVidia).

And were are here in the niche market, not majority, and here AMD has much stronger representation than in overall picture. Anyway, why are you supporting Linux or OS/2? Windows has 90% of the market (it's significantly greater dominance that Intels in PC CPU business)? :)

rgds
Sebastian Kaliszewski

Hi,

I don't think so, because the marked for for 64-bit consumer PCs is empty.

The IA64 is a very good design. But it is so complex, that the CPUs will be too expensive for home usage. AMD Clawhammer will be sold in two (or maybe in one) year by Aldi! The x86-64 CPUs will be the continuation of the x86 line (take a look at the AMD processor roadmap: http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_608,00.html ).

What I suspect what happens is if the x86-64 gets too big and the iA64 fails Intels extend the x86 architecture as well to 64 bit

If Intel starts to develop their own 64-bit extension for x86 in 2002 they will finish their design not before 2005, when AMD x86-64 is already established.

I'm wondering a little bit that you write the IA64 support first. It's a totally new design. For using the full potential a good optimization is required. (That means loop analysis, unrolling, ... ) It's a big challenge.

Concerning optimization, I'm not a compiler expert, but isn't it possible to make the backend compatible to the backend used by Intel Fortran and C/C++ Compiler. Replacing the fpc backend by the Intel backend would result in a dramatically faster Programs, especially for P4 and IA64 in the future. That's just an idea, I'm not a expert.

Regards
Stefan

----------------------------------------------

http://www.simage.org

------------------------------------------------------------------ In a world without walls and fences, who needs Windows and Gates ?

There is just one thing I want to add to your excellent explanations: There are strong indications that Intel's second CPU team is already working on a solution for the case that x86-64 will succeed. Of course, Intel won't officially admit this, because this would show that they don't believe in IA64 any more.

Another thing, regarding Hammer vs. Itanium: The die size of the Hammer CPUs will be much smaller than those of Intel's CPUs. If AMD will really decide to start a price war with Intel, chances are good that AMD will win this fight. Simply because Itanium and its successors will be much more expensive to produce.

- Sebastian

For the next five years I agree totally.

I'm wondering a little bit that you write the IA64 support first. It's a totally new design. For using the full potential a good optimization is required. (That means loop analysis, unrolling, ... ) It's a big challenge.

Yes I know, that's why I'am interesseted in it :).

But another point is, a x86-64 port can be hacked quite quick together. The only real problem are the calling conventions. I'll play around with it :), it will prove the portability of the new fpc back end and it will surely improve the 64 bit awareness. If something happens, you'll see it in the cvs.

Theoretically yes, but is it possible to access the intel back end? I.e. is the interface documented?

The worst thing about current IA64 is the carry-over of legacy support. A dual instruction set chip is the most disgusting thing I've ever heard of... Okay its not as bad as HCF but it's close. =P DAMN!!!

CUT
THE
FAT

Hi,

Theoretically yes, but is it possible to access the intel back end? I.e. is the interface documented?

Some weeks ago I read an article in a magazine (I think it was iX magazine) about the Intel compiler (there was also another article in the c't) There stand that the backend is a separate program (and I think the C++ frontend is from an other party than intel). I have no information about a public document about the backend interface. But in my opinion Intel would be stupid if they don't give this information to compiler developers.

Give me an fax number, if your are interested in this articles.

I downloaded the Fortran package today. But I have not installed it yet. (It requires a newer rpm version - such a rubbish - than I have. And I don't feel like installing a new rpm because I have no time at the moment).

As far I know the Inprise C++ 5.0 compiler is compatible for the intel backend. So the Inprise C++ packages contain two backend, the Inprise backend and the Intel backend. (The intel backends compile very slow, but they produce the best code)

Regards
Stefan

----------------------------------------------

http://www.simage.org

------------------------------------------------------------------ In a world without walls and fences, who needs Windows and Gates ?

Sorry, but what is HCF?

An old computer myth.
There was once a machine with a serious hardware flaw such that entering a certain bad opcode, lets call it "HCF", caused the machine to go into a strange halt state in which the address lines coming out of the processor are toggled in a rapid-feedback loop. As you know, changing the state of a line requires an expense of energy which causes the release of heat. The ultra-rapid toggling of these lines would lead to an immense heat buildup eventually causing a fire. So HCF has the effect of causing the machine to Halt and Catch Fire. =P

Google should be very helpful in giving more inf0z...

Hi,

Let me contribute a totally different version of the HCF thing .. I programmed 8-bit microprocessors in the early 1980s, and I remember of one -undocumented- instruction, that caused the processor (I think, 6502, 6800 or somthing like that) to increment it's address lines forever. I don't remember if it really was CF, but if someone is interested in this I can look for it.

We actually used this instruction, because a processor simply incrementing it's address lines is very helpful in finding hardware errors, because nearly every pin in the whole system then shows a certain 'signature' (that is, low - high - transitions over all 65536 addresses). After executing this HCF instruction, we could compare the signal on each pin with a printout of an error-free hardware.

I don't know about a fire, but I agree that the power consumption may rise in this mode.

I don't know either, if this instruction was really a flaw or if it was intentionally designed for hardware testing.

Hope I could add some confusion to this myth.

Anton.

No, no!
It simply means : Host Computer Failure
( ... however, the abbreviation is sometimes used for 'Hexadecimal Code Fragment' )

Patrick Mergan
email :