Hello,

I was going over the wiki and looked at
http://wiki.freepascal.org/FPC_New_Features_Trunk . It looks like some of the features here, actually breaks Pascal, and create something like Jascal or something, but it's not Pascal in spirit.
For example 1000.to_string ?! I have it on Ruby and Java, but it's not Pascal syntax.
Same goes for array constructors.

I actually starting to ask the same questions of Graeme, do we really want to follow Delphi instead of creating a more Pascal like dialect ?

Thanks,
Ido

ik wrote

For example 1000.to_string ?! I have it on Ruby and Java, but it's not Pascal syntax. Same goes for array constructors.

Both of those are just hideous to me. Very un-Pascal like. :-(

I actually starting to ask the same questions of Graeme, do we really want to follow Delphi instead of creating a more Pascal like dialect ?

And to make matters worse... FPC isn't very Delphi [2009 and later] compatible anyway. It copies some features but not all. Then the some it does copy might not be fully functional yet, or has a different syntax. I tried multiple times to make a Delphi 2009+ project of mine work with FPC 2.7.1, and I just can't succeed. I fix or work around one issue, just to be blocked by another.

I still believe FPC should leave the "delphi compatible" idea, or clearly state that it means "compatible with Delphi 7 for legacy purposes" and nothing newer. Then innovate the rest of the language on its own in a Pascal-like manner.

FPC now definitely finds itself in the Jascal.NET territory. ;-)

Regards,
- Graeme -

I still believe FPC should leave the "delphi compatible" idea, or clearly state that it means "compatible with Delphi 7 for legacy purposes" and nothing newer. Then innovate the rest of the language on its own in a Pascal-like manner.

This is a terrible idea. The business advantage of Object Pascal has always been the component market, as it reduces development costs and time to market. Language compatibility between FPC and Delphi results in more components being available on both sides.

The Object Pascal language is too fragmented already, and depending on your choice of the Delphi/FPC/Oxygene/whatever flavour, you are locked out of a hell lot of available source code, documentation, knowledge and components. Right now pretty much every commercial component we have to patch inhouse to be compatibile to FPC.

(On a side note: It's one of the goals of CrossFPC to make it easier for Delphi users and component vendors to also use/support the FPC compiler.)

Sticking to D7 compatibility has been OK for now as this is what the masses and component vendors mostly are doing, too, as they still have to support D7 users.

We ourselves have to stick with D7 language level because we still need CrossKylix for our Linux builds because the FPC compiled code is prohibitively slower than Kylix' one.

FPCs goal to move towards D2009+ language compatibility is a right goal - but of course that does not mean that everything needs to be copied, but when things on the Delphi side are designed in an OK manner, are actively used in the field, and FPC wished to do the same, aiming for compatibility is a good thing. Should FPCs share of the object Pascal ecosystem one day should be *significantly* larger than Delphi's, sooner or later Delphi then will try to pick up FPC's innovations instead.

In the long run, new object pascal language features optimally should be discussed by those active in the field BEFORE they get implemented. Sadly right now Embarcadero still are far too arrogant and close-minded to understand that FPC actually benefits the ecosystem they sell products in.

All this being said: I know that FPC is not after business goals. But not damaging the ecosystem FPC works in helps everyone using Object Pascal, no matter if they are after commercial goals or not.

Cheers,

Simon

Graeme Geldenhuys wrote

FPC now definitely finds itself in the Jascal.NET territory. ;-) Regards, - Graeme -

That's probably needed here. I think it's a great idea to embrace a new name for some future version that includes innovations. Pascal has been forced into a bracket it ought-not-be.

Jascal DOES look cool ;-)

Simon Kissel wrote

This is a terrible idea. The business advantage of Object Pascal has always been the component market, as it reduces development

Component vendors simply aren't interested in FPC, and those that are, are bought about by EMBT and made Delphi only.

We ourselves have to stick with D7 language level because we still need CrossKylix for our Linux builds because the FPC compiled code is prohibitively slower than Kylix' one.

I stumbled across this last week too. On the same OS, I compiled the exact same unit testing test suite using FPC 2.6.0 and Delphi 7. Running those tests, again on the same system, the Delphi executable completes the 180 tests in 2 seconds. The FPC binary took 18 seconds for the same 180 tests!!!

FPCs goal to move towards D2009+ language compatibility is a right goal - but of course that does not mean that everything needs to be copied, but when things on the Delphi side are designed in an OK

If you want to say "delphi compatible", it must be all or nothing. EMBT is butchering the Delphi name to hell and gone. I don't think FPC should follow just because.

A few issues aside, I honestly believe FPC is a much better product than Delphi. FPC should build on its strengths - it doesn't need Delphi.

eg: In a recent discussion in the Google+ Delphi Community, they asked what new language features would Delphi developers like. After about 15-20 replies I had to post a message saying that FPC actually supports most of the things they had on their wishlist.

As I said, FPC doesn't need Delphi. Innovate on your own and don't follow Delphi into the grave. Plus, stay true to the Pascal language as much as possible.

Regards,
- Graeme -

Andrew Brunner wrote

Jascal DOES look cool ;-)

That will probably rid us from some of the Pascal Language stereotyping. :)

RemObjects (with their Oxygene language) tagline says it best:

"This is not your daddy's pascal"

I love that tagline.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Component vendors simply aren't interested in FPC, and those that are, are bought about by EMBT and made Delphi only.

Eldos added support for Free Pascal to SecureBlackBox within the last couple of years. Indy supports it in their main repository. I added FPC support to Abbrevia in late 2011.

I know we're not the only commercial software vendor to give up on Delphi for cross platform work, and Free Pascal's Delphi compatibility is the only thing that has made that possible.

If you want to say "delphi compatible", it must be all or nothing.

Why? It should be driven by user needs and developer interest, just like it always has. I'd like to see anonymous methods because it would make porting the OmniThreadLibrary possible. The fact that they aren't supported doesn't make the existing generics and class helper support unusable.

Component vendors are interested in selling components.

The honest loyality of component vendors to
Borland/CodeGear/DevCo/Embarcadero is next to non-existant. The reason Delphi is the focus
is that they invested into that, and that Embarcadero is using anti-competitive tactics.

I've been a Borland Technology Partner. Besides my personal experience, I sure know how component vendors are treated.

Supporting FPC just has be to be attractive enough so that the component vendors are willing to take the risk of not getting any more "love" from Embarcadero.

Removing technical obstacles therefore helps. Language compatibility is something that helps a lot.

From our measures the Delphi and Kylix compilers in most cases on x86 produces code that is about in the order of 50% faster than FPC. So probably there is some issue specific to your test suite that is triggering this huge difference, it should not be that big. For some applications (like ours), still the difference is too big, so we only use FPC on platforms where there is no compiler from Embarcadero, and keep all of our source code compatible to Delphi 7 + Kylix + FPC. Language compatibility enables us to have a choice. Without this choice, we would have needed to move to a different programming language. Choice is good, competition is good, compatibility amongst competitors is good.

Cheers,

Simon

You mentioned that you would like to contribute to FPC. Maybe this is an area where you can contribute: more aggressive optimizations.

Michael.

As long as it has the dangling-else flaw, it's Pascal.

In our previous episode, ik said:

We already have had this discussion for VB (D4/COM extensions), .NET etc.

Yes Delphi will copy everything what is popular in a desperate attempt to increase its appeal.

I actually starting to ask the same questions of Graeme, do we really want to follow Delphi instead of creating a more Pascal like dialect ?

FPC is not clean either. Constructs like case string of remind of basic and the proposed tuple support is not exactly hardcore imperative languges (let alone Pascal) either.

In our previous episode, Graeme Geldenhuys said:

So "Sulphur" then? It is the next element in the same group of the periodic table and twice as heavy as Oxygen? Moreover hints at being a bit evil and vile.

The idea behind hinting on that last bit is if we simply admit we are dirty, we won't have any useless cleanness discussions anymore?

2013/2/28 Simon Kissel :

So let's call the Delphi-compatible version "Rascal" ? ;)

All this being said: I know that FPC is not after business goals. But not damaging the ecosystem FPC works in helps everyone using Object Pascal, no matter if they are after commercial goals or not.

I agree. We need better optimisations at least as much as fancy 123.tostring. Is there other companies here interested in Linux 64 bits target optimisations ?

But the syntax is Pascal-ish, case did not changed, only expanded, and it actually have a good use.
I don't know the tuple part well, so I can't comment on it.

The for in with FPC is nice, and it's a syntactic sugar, but still it did not break Pascal syntax.
The ability to have mixin for "primitive" types, or arrays is something completely different here.

to_string is syntactic sugar to val or IntToStr, but it's not Pascal, it's Object based syntax, something we do not have in Pascal at the moment.
And if you do want to have it, then first start to make everything like it, and then add the mixin, or it's actually make the code less readable, and much harder to maintain, unlike the other "unclean" features, such as case for strings.

Ido

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

The main language dialect used with FPC (though its not the default one) is Object Pascal, not Pascal. If you want Pascal, then stop using classes immediately! Object Pascal unlike Pascal is not defined anywhere as the driving force behind it is Delphi.

I personally don't agree with some syntaxes as well, but I'm mostly all for the feature they represent.

For example anonymous functions: ugly as hell, but this concept of closures is awesome. When the anonymous methods from Blais' branch will be ready for merging I'll extend the so far that we can also pass nested functions to them (which isn't allowed in Delphi), so that one can use it's power without cluttering the code. Also I'll think about adding a less verbose syntax for simple cases (more lambda syntax like, but more Pascal like than the variation from Oxygene).

Another example: Attributes. The idea that you can tag attributes to classes, their fields and methods is a wonderful one. This way you can group additional information (e.g. DB field, HTTP Parameter, etc.) together with the element it represents. It also opens the possiblity for automatic Dependency Injection which can reduce code coupling (which is good except for performance "critical" systems like the compiler) and thus also simplyfy testing. Yet I find the syntax absolutely un-Pascal-like. Those prefixed attributes are simply copied from C#. My plan is currently before Joost's branch with attributes is merged that I extend the syntax in mode ObjFPC to be a suffix instead like "virtual" and "deprecated" modifiers behind which the attributes in a "[...]" block follow.

And for array constructors: I would prefer "somearray := [ element1, element2, element3 ];" instead and maybe I'll implement that somewhen in the future :)

For the type helpers I've also done something more consequential: in Delphi helpers for primitive types are declared as "record helper" while in ObjFPC they are declared by "type helper". It's very likely that I'll allow the usage of records in "type helper" as well and "deprecate" the record helper syntax in ObjFPC (it will be kept of course for backwards compatibility to 2.6.x).

I actually starting to ask the same questions of Graeme, do we really want to follow Delphi instead of creating a more Pascal like dialect ?

As others already said: There are components or frameworks out there that use modern Delphi features or frameworks of other languages that make use of such features. Example: DSpring, which is a Delphi dependency injection framework. Another example I'd like to see is .NET's Reactive Extensions which allow you to work with asynchronous data streams (which requires interface helpers and closures).

Maintaining a language is not only about satisfying users that are happy with the current state. Languages evolves and so should do Pascal. While we currently do follow Delphi's lead my plan is to also research (not necessarily implement in trunk!) language features that aren't found in Delphi, but in other languages. Features like type inference, duck typing, aspect oriented programming and traits. By implementing them we can attract developers which got used to such features and swear that they can simplyfy work. Yet I'm also aware about the heritage we have and that we must honor it. Which is why I want to implement no language features in an as Pascal way as possible and which is also why I was opposed to the tuple feature as suggested by Alexander.

Regards,
Sven

Sven Barth wrote

[...] Features like type inference, duck typing, aspect oriented programming and traits. By implementing them we can attract developers which got used to such features and swear that they can simplyfy work.

But there should be a line that nobody will cross. Otherwise someday someone try to attract PHP developers with removing the type safety from Free Pascal. *shudder*

Michael

I can guarantee you that *I* won't be the one who will cross that line ;) Type safety is one of the main features of Pascal based languages and without that it would definitely not be Pascal any longer ^^

Regards,
Sven

Marc Pertron wrote

We need better optimisations at least as much as fancy 123.tostring.

Bottom line.... optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that.

Regards,
- Graeme -

ik wrote

But the syntax is Pascal-ish, case did not changed, only expanded, and it actually have a good use.

+1

Regards,
- Graeme -

Sven Barth wrote

Which is why I want to implement no language features in an as Pascal way as possible

I very much appreciate your efforts, and do like the fact that you try and keep new language features more pascal-like. Kudos for that.

Regards,
- Graeme -

An llvm target will move the optimisation burden away from fpc, which would be very interesting.

Henry

Well:

{$mode jascal}{$H+}

:)

Optimisation is also not necessarily easy. Especially if you are on the assembler level you need to know the CPU's characteristics. I might dive a bit deeper into the topic of optimizations once m68k is ready for optimizations... (currently I only use -O- there :) )

Regards,
Sven

Ironically this is the direction Embarcadero is moving. They've already made the transition with their C/C++ compiler and there have been hints that Delphi is next. In a way it makes sense. They get an instant boost in runtime performance and can focus more of their resources on the compiler front end, libraries and IDE.

Not just performance, they gain access to all the architectures that llvm supports.

Henry

In our previous episode, Kenneth Cochran said:

And, like LLVM, they only care about popular targets anyway.

As others already said: There are components or frameworks out there that use modern Delphi features or frameworks of other languages that make use of such features. Example: DSpring, which is a Delphi dependency injection framework.

I did not find DSpring. Do you mean Spring4D? If this is the case I'd rather stay with the real thing (meaning Spring Framework for Java).

By implementing them we can attract developers which got used to such features and swear that they can simplyfy work.

This I highly doubt. Why should I change languages only because FPC now has a feature that I already have in Java/Ruby/Groovy/etc and leave all the libraries and frameworks behind to get win32 only frameworks that are chasing the features of the multiplatform ones I left? If you are not a Pascal guy you won't become one just because FPC supports closures or dependency injection or whatever. Delphi is trying hard to stay relevant and so is FPC by following because becoming too different to Delphi will make the community quite a bit smaller. That's all there is to the new features. Pascal is a niche language and will stay one. There won't be the year of Pascal and suddenly thousands of developers start using it. You may write the next Facebook in FPC and it won't matter.

R.

Marco van de Voort wrote

So "Sulphur" then? It is the next element in the same group of the periodic table and twice as heavy as Oxygen? Moreover hints at being a bit evil and vile.

Won't work. The truth is:
1.) most don't kown/know their current state.
2.) those that do, are rightly wanting to align properly. 3.) loss of naturally good talent (it only takes one bad idea to misguide) 4.) draw of skilled talent that binds contention.
5.) there is a measurable force that supports M$'s (project of the day). The force involves collective conscientiousness. And control over perception. The social fabric is presently being shaped in their favor. From our perspective, no-one ever lost their teeth buying Microsoft's Windows. But from their perspective, no-one ever lost their job buying a M$ project. Both perceptions are negative towards the truth. Proof to me that they have successfully adopted a viable strategy. 6.) Collective conscientiousness demonstrates that Pascal is a dead language. So either we overcome the notion that the language is dead (my favourite) or perhaps call it something else and try to ignite a spark and see what happens.

The idea behind hinting on that last bit is if we simply admit we are dirty, we won't have any useless cleanness discussions anymore?

With strong acting/performance project, cleanliness is just inherent. So I would say sure.
With such a project, bad code would be limited to reflect on the code contributor/creator.
But to 1.) above, wrongly kowning up to bad code contributions is my largest genuine concern.

Btw, there is already an object pascal implementation targeting llvm. https://code.google.com/p/llvm-pascal/

In our previous episode, Kenneth Cochran said:

Btw, there is already an object pascal implementation targeting llvm. https://code.google.com/p/llvm-pascal/

I know. Afaik it was for teaching purposes though, not for production.

Simon Kissel wrote

All this being said: I know that FPC is not after business goals. But not damaging the ecosystem FPC works in helps everyone using Object Pascal, no matter if they are after commercial goals or not.

The mission goal of FPC is to provide an OSS pascal compiler in a community effort by pascal users so this implicitly means that we try to avoid to destroy the ecosystem we are living in. So FPC tries also to support as much as possible pascal dialects. Actually, nothing prevents people to provide a completly rewritten rtl throwing old stuff away but it must live together with the existing one.

Staying with the bazaar and cathedral metapher: one can always build up his own market stand in FPC's bazaar. But one cannot come with a big bulldozer and remove other people's stand to make room for the own stand.

Yes, sorry, I did indeed mean Spring4D. And staying with the real thing does only help if you use Java...

> By implementing them we can attract developers which got used to such features and swear that > they can simplyfy work. This I highly doubt. Why should I change languages only because FPC now has a feature that I already have in Java/Ruby/Groovy/etc and leave all the libraries and frameworks behind to get win32 only frameworks that are chasing the features of the multiplatform ones I left? If you are not a Pascal guy you won't become one just because FPC supports closures or dependency injection or whatever.

There are people that aren't as fixed with their programming language as me (though I DO use C/C++ or even Java if the need exists...) and do take a look here and then for other languages, because they might be unhappy with a few things. I have a friend for example who is - in his company - a PHP developer (and he likes it), but when he started a bigger hobby project he had taken a look at Free Pascal and liked it.

Delphi is trying hard to stay relevant and so is FPC by following because becoming too different to Delphi will make the community quite a bit smaller. That's all there is to the new features. Pascal is a niche language and will stay one. There won't be the year of Pascal and suddenly thousands of developers start using it. You may write the next Facebook in FPC and it won't matter.

The interesting thing is how long can we afford to follow Delphi? They added a {$ZEROBASEDSTRINGS} directive in XE3, added type helpers (they didn't just add them because of nothing) and seem to want to add automatic reference counting to TObject. Put this together with them developing a completely new compiler and this *might* lead to them dropping backwards compatibility. This event would be - in my opinion - where we definitely need to stop swimming in their backwash and steer free.

Regards,
Sven

Nice metaphor :-)

Well put.

Michael.

While we would welcome a LLVM backend it is basically a consent in the development team that this would only be an additional alternative to the normal backends FPC provides.

Regards,
Sven

Yes, sorry, I did indeed mean Spring4D. And staying with the real thing does only help if you use Java...

Which was implicit. Choosing the right tool for the job (in this case Spring). If this means using a different language so be it.

a PHP developer (and he likes it), but when he started a bigger hobby project he had taken a look at Free Pascal and liked it.

PHP and developer in the same sentence, funny stuff. :) And he likes Pascal because of class helpers, (upcoming) closures and all the other fancy new stuff? If not your anecdote does not fit the may also like it because pascal is a nice and clean language which is easy to learn and not because of the new features. But your point was that new developers come to FPC BECAUSE it now has the stuff they are used to. And this I doubt.

This event would be - in my opinion - where we definitely need to stop swimming in their backwash and steer free.

My opinion has always been that neither FPC nor Lazarus should try so hard to be compatible. Doing your own stuff instead of following Delphi downhill has its benefits. But this is all up to the developers and not my business. If I don't like the changes, I don't have to use them. Easy as that. Looking forward to seeing FPC 'steer free' because then I can grab my skates and go ice skating in hell. :)

R.

For me it's more about providing the FPC users with the possiblities to nicely do things like dependency injection, etc.

> a PHP developer (and he likes it), but when he started a > bigger hobby project he had taken a look at Free Pascal and liked it. PHP and developer in the same sentence, funny stuff. :) And he likes Pascal because of class helpers, (upcoming) closures and all the other fancy new stuff? If not your anecdote does not fit the may also like it because pascal is a nice and clean language which is easy to learn and not because of the new features. But your point was that new developers come to FPC BECAUSE it now has the stuff they are used to. And this I doubt.

Ehm... ok... that was indeed a bad example -.-

> This event would be - in my opinion - > where we definitely need to stop swimming in their backwash and steer free. My opinion has always been that neither FPC nor Lazarus should try so hard to be compatible. Doing your own stuff instead of following Delphi downhill has its benefits. But this is all up to the developers and not my business. If I don't like the changes, I don't have to use them. Easy as that.

We have different language dialects after all. As I already wrote in one of my previous mails I try to implement Delphi features in a more Pascal like way if I see it fit. And with most of the principles BEHIND that features I agree (e.g. attributes, closures, etc.).

Looking forward to seeing FPC 'steer free' because then I can grab my skates and go ice skating in hell. :)

I wouldn't mind the hell not freezing over even if we steer free... I'm saying this after I've spent most of the day in a +6 degree celsius cold satellite antenna... (
https://ssimuc.de/content/pmwiki.php?n=Main.Groundstation )

Regards,
Sven

Hi,
first of all: no matter what - stay with 'Free Pascal' - I don't think there would be any advantage renaming a project - except for the whole project loosing its identity.
My experience is that most people don't even know Pascal - I wouldn't say Pascal as a language has a bad reputation.
[Every time a program crashes with segfault or similar, I wish it had been written in Pascal... :) ]

But the syntax is Pascal-ish, case did not changed, only expanded, and it actually have a good use.

+1 from my side, too.

I wouldn't see it as closely. Only dead languages are static - there is no good reason to hinder well thought out features to be added, as long as they support the IMO most important two goals of Pascal: readability, and type safety.

BUT: the sheer amount mustn't be decisive - feature bloat can have very negative effects...

Optimisation is a topic which really needs to be discussed - maybe when fpc reaches a (temporary) state of temporary 'feature completeness'. [lets 2.X be the feature version, 3.X the optimised version :D ] Especially for mobile targets well optimised / efficient programs have great advantage, but the problem mostly is not speed, but energy consumption. [Btw. big thanks for merging the android branch +100]

Nice to hear, that the option to 'detach' from Delphi is considered here as well, as I'm sure there will be no other option sooner or later...

Last OT:

I wouldn't mind the hell not freezing over [...]

Nice...
It's pretty damn cold in this area (almost at my front door) for this time of the year, so that's really a valid wish... :)

Regards,
d.l.i.w

first of all: no matter what - stay with 'Free Pascal' - I don't think there would be any advantage renaming a project

We were only joking around with the name. :)

Regards,
- Graeme -

All the new "strange" features doesn't really matter as long as:
1) the backward compatibility is in place (and or guidelines are given how to make the code compatible with minimal efforts)
2) executable size doesn't suffer much ;)
3) the new target is supported and the existing code can be applied to it.

Luckily, syntactic sugar is really optional and it is up to developers to discipline themselves not using it. It might be unavoidable to interface with a target platform, but in this case "unholy unpascalish" code can be locked away into a separate unit, to keep the cross-platform core library nice and clean. Self-discipline.

thanks,
Dmitry

The problem with this is that you cannot read code written by others anymore unless you learn *all* details about the large number of added "features". And that's meanwhile like learning 2-3 other languagues and no longer the easy to learn Pascal of earlier times.

Agreed 100%. I think this is a very important argument against to add not necessary extensions to the language.
I would try to unify existing features and make them "orthogonal" instead and move advanced tasks into libraries.

Martin

We were only joking around with the name. :)

Fully understood, but just to be sure :D

d.l.i.w

I don't think that's possible in the general case, unless the parser etc. are completely rewritten to allow things like the <generic> or (tuple) notations to be defined in the same way that operator overloads are today. And in any event, there might be so much overhead stuffed into e.g. stackframe handling to support features that the compiler doesn't know aren't being used "nearby" that performance and maintainability both suffer.

LLVM's target list doesn't look particularly brilliant compared with FPC's :-/

Are there any practical advantages to having both? Could inspecting LLVM output help in getting a native code generator off the ground, or does it output enough debugging info to suggest novel optimisations?

Yes, that's another reason why we wouldn't use it as default :)

Are there any practical advantages to having both? Could inspecting LLVM output help in getting a native code generator off the ground, or does it output enough debugging info to suggest novel optimisations?

The point is: if we introduce a LLVM backend then why not use it for the LLVM supported targets as well. The current (as in "in the last few weeks") driving point for a LLVM backend is the possiblity to use Emscripten to convert the generated LLVM code to JavaScript and run the resulting executable in a browser.
Also if we have a backend independant of FPC we could check whether only our backend optimizations are bad (LLVM can generate very optimized target assembler code) or whether we should improve our frontend optimizations (those that are done on the Abstract Syntax Tree). So the introduction of LLVM could be seen as a step closer to better optimized code.

Regards,
Sven

How do you mean? It supports more architectures than FPC, as far as I can see (http://llvm.org/Features.html). They also have a C backend that you can use for targets that they don't support.

Henry

Targets supported by FPC and LLVM:

i386
x86_64
PowerPC
PowerPC64
ARM (including Thumb)
Sparc
MIPS (in how far does LLVM support LE and BE and 32 and 64 bit variants here?)

Targets supported by LLVM only:

Alpha
CellSPU
MSP430
SystemZ
XCore

Targets supported by FPC only:

AVR
(AVR32 [in a branch])
M68k
(JVM [in brackets, because JVM uses a high level code generator like LLVM would do])

And you should also not forget that LLVM needs to be able to generate code that's fitting for the target operating system. Think about the more exotic ones supported by FPC: DOS, OS/2, GBA, NDS, etc. Also there are only Windows binaries provided for Win32 and these are considered experimental...

But even if LLVM would support all targets that FPC supports the core developers don't *want* to make LLVM the default.

Regards,
Sven

I'm not denigrating it and I note Sven's points, but no 68K, no AVR, no JVM. "Brilliant" in this context would have been every 32/64-bit architecture that has a compatible assembler (presumably, GNU as).

My concern also...This is happening with many projects I've seen. Everyone wants the benefits of LLVM, but it leaves all but the most mainstream targets unsupported.

Are there any practical advantages to having both?

Personally I can only hope additional interest in LLVM will lead to more supported platforms. I understand they don't have manpower for every platform but as it is the narrow focus is certainly a concern, especially when big projects like FreeBSD move away from gcc and make LLVM the official "compiler of FreeBSD". Whether it's related or not, FreeBSD seems to have back-burnered everything that's not Intel...

+1

platform but as it is the narrow focus is certainly a concern, especially when big projects like FreeBSD move away from gcc and make LLVM the official "compiler of FreeBSD".

I don't know anything really about LLVM, but did read recently the comparison betweer GCC and LLVM under the latest FreeBSD. 20-30% faster compiles, much less memory usage etc. But then FreeBSD really had no choice, because GCC & GDB moved to GPLv3, which FreeBSD can't support. Hence the default GDB is v6.x (luckily the ports collection has v7.x).

Whether it's related or not, FreeBSD seems to have

back-burnered everything that's not Intel...

Um strange. FreeBSD recently announce they have added support for the Raspberry Pi. That's not Intel.

Regards,
- Graeme -

In our previous episode, Sven Barth said:

But even if LLVM would support all targets that FPC supports the core developers don't *want* to make LLVM the default.

At the very least, no irreversible decisions should be made for LLVM is running at least a full version cycle in production.

So people wanting LLVM, should work on getting LLVM online, discovering issues etc. It is only decision time when it is full evaluated.

In our previous episode, said:

FreeBSD was always the least cross-platform of the bunch. PowerPC was still beta when the platform was already dead to Apple.

Not surprising for an OS that started as a patchkit for 386BSD :-)

Sven Barth wrote

But even if LLVM would support all targets that FPC supports the core developers don't *want* to make LLVM the default.

Actually, I wouldn't have any interest working on a compiler using llvm as a backend because it leaves only the boring front end work :) Not to mention the maintainance problems when depending on an external cg written not in pascal, the probably significant speed drop etc.

I've already thought whether I should write that you are one who is at most against LLVM as a backend (though I do mostly agree with you), but then I thought that I leave it just as general as I wrote it ^^

Regards,
Sven

In our previous episode, Sven Barth said:

I've my doubts too. Not so much that I crave backend work (since I don't work on the compiler), but from a release engineering viewpoint.

The external codebases and -versioning are always the problem.

People at Delphi are unwilling to call themselves Pascal developers (Or Object Pascal), but Delphi developers, now I understand the lack of cooperation that the FPC developers talk about.

But if Delphi devs, does not wish to see themselves as Pascal developers, then how does FPC implementing Delphi dialect can help ? Or is it just a core group of people ?

----- Oorspronkelijk e-mail -----

as a matter of fact, the llvm-stack is not just your front-end to provide the intermediate bytecode (or textual variant)! You can provide/maintain multiple plugins for almost every "pass". Going from optimisation passes to the entire "executable generation" as back-end. Admittedly you need to make a C(++?) compatible interface, but I think nobody stops you from making those passes/plugins in FPC...

on the other hand... the speed difference with Delphi XE 3.5 or later would level out a bit more :-)

that being said, Embarcadero will surely implement such proprietary passes/plugins and additions for their own benefit.

At least I am very curious to next fall when the next version(s) come out. Not in the least if they also support Android with a cross-platform library/interface between iOS and Android for common features, like they 'promised' last fall on a conference. (BE-Delphi last november)

full disclosure: yes, paying owner of a licence DXE3

kind regards,
Dimitri Smits

And how does this change the fact that it is an external cg not written in pascal?

----- Oorspronkelijk e-mail -----

Van: "Florian Klämpfl" Aan: "FPC-Pascal users discussions" Verzonden: Maandag 4 maart 2013 21:00:10

And how does this change the fact that it is an external cg not written in pascal?

the front-end would still be written in pascal.

as a matter of fact, when you use the binutils and ld etc, you aren't exactly using a full pascal toolchain either, no?

kind regards,
Dimitri Smits

exactly using a full pascal toolchain either, no?

Unlike the binutils which are basically available on and for every platform LLVM is not. Also we are trying on some plattforms to reduce or remove the need for external non-Pascal tools.

Regards,
Sven

But the back end not, right ;)?

as a matter of fact, when you use the binutils and ld etc, you aren't exactly using a full pascal toolchain either, no?

Of course I do. My desktops run all windows and fpc for win32/win64 has no need of as or ld (guess why ;)). fpc contains an assembler and linker for win32/win64. Actually, fpc even supported win64 before binutils for it were available due to this.

Hi,

I tend to agree. More specifically, I personally like the idea os having Pascal be its own run-time (or, ahem, compile time) environment, somewhat like Java, more than a bare-bones language like C. We can have compatibility of built-in functions and syntax, while having a native compile system - which gives us some advantages over both C and Java.

The Object Pascal language is too fragmented already, and depending on your choice of the Delphi/FPC/Oxygene/whatever flavour, you are

Oxygene may be cool and all, but I think it's not really pascal anymore. Delphi has most of the time used the term "ObjectPascal" hidden in their documentation, and it is clear that it is an evolution of TurboPascal. Oxygene (and Delphi.net) seem to be much more clean breaks "in the pascal style" to me.

locked out of a hell lot of available source code, documentation, knowledge and components. Right now pretty much every commercial component we have to patch inhouse to be compatibile to FPC.

Yes, on the GUI level, I wish things would be more compatible, not less. I don't like having to convert forms, etc., much less code.

I can only trust that this is true. I used to be a Delphi programmer at work, but now it's only for small projects. (When I do major programming at all, it's in ABAP or sometimes Java).

Heh, I noticed this when porting the FPC run-time-library to VirtualPascal in like... 2001 or so. It worked, but it was much much slower. This is something that would be great to fix, but on the other hand, doing it in Pascal Source means there are some limitations. Still, it would be a great summer of code project.

I wonder if it isn't already. Simply not for large businesses.

Well I don't know if I would use the fighting words, since I haven't met them personally. They probably have mixed feelings about FPC. On the one hand, we are on their team, and FPC allows them to support iOS, etc. (I am sure they see the advantage in that!). On the other hand, we are to some extent a competitor as well. Delphi has certainly become less popular since v6, and I think FPC has probably become more popular.

Still, I think that if FPC wants to do something that Embarcadero has no interest in, then we can do it our own way. If they implement a feature in a certain way, we should try to mimic it as closely as possible in order to have the highest code compatibility. The worse case I have seen right now is where we implement something, and then they come along and implement it differently (ahem.. generics). They should realize that a lot of people use both products, and all kinds of forums to find answers on. Then they look up "How to use generics in Pascal", we want there to be one single correct answer. Not like "Well, if you're using Delphi it will be this way, and if you're using FPC it will be this way", because most of the time, specific products names may not be mentioned.

All this being said: I know that FPC is not after business goals.

I think FPC is after having as many users as possible and developing a high quality system. Clearly, the goal is not just "Develop a TP7 clone so we can compile old DOS programs." (That may be some people's goals, however clearly other people want more).

I am actually impressed with FPC in some ways because while progress has been slow, it has enabled a lot of things over the years. You can now compile GUI programs on Mac just as easily as on Windows, and there are code generators for the Java VM, etc. Clearly FPC authors aren't afraid to experiment and try new things.

But not damaging the ecosystem FPC works in helps everyone using Object Pascal, no matter if they are after commercial goals or not.

Not to mention, there are commercial products that become open source (like OnGuard, etc.), as well as hobbyist/research projects that eventually become commercial. The line between the two is getting thinner all the time, and we would like our code to be as portable as reasonably possible. Pascal is already a niche compared to Java today, so let's not fragment a niche where we don't have to.

That said, of course we can't predict what the Delphi people will do. If they suddenly go crazy and start implementing things in a way that doesn't make sense, nothing is to say we have to copy "Delphi 2020" 100%.

Cheers,

Thank you,
Noah Silva