Funny that you say that about the Oxygene language. To me the language
concept and marketing screams ".NET me too wannabe".
Remobj is one of the few companies that bring the cross-platform
features, and thus the promising future of CIL (aka ".NET" in Microsoft
speak) up to front. They, too,
> Provided that it's a lot easier to create a compiler for CIL than
> creating it for multiple CPUs and OSes, IMHO, this is the way to go on
> the long run. (But of course native code will widely be in use for
> several years to come :) ).
If this was true, Java would have taken that market a
Well, then where are the major new features of Oxygene? Where, what?
I already did rant about "future" and "async".
If there would be much more I would already have bought it :) .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.or
On Tue, Jul 29, 2008 at 5:50 PM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
>> Boost the usage of Unicode in FPC that would boost the usage of FPC
>> itself. Unicode is one of the most demanded features (beside cross platform,
>> 64bit support, etc) in Delphi since Delphi 7 (2001?). Yet, CodeGear n
If this was true, Java would have taken that market already. There is
nothing new to that aspect of CIL, and specially with only one minor vendor
supporting it.
Basically you are right, but
- In fact Java is very widely in use (even though there are lots of
shortcomings regarding Java )
-
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>:
> [...]
> If FPC didn't worry
> to much about compatibility and instead implemented Unicode support
> long ago like it could have, it might just have boosted FPC usage,
> beating Borland to the punch by about 7 years. FPC could have
> attracted and
> On Wed, 30 Jul 2008, Graeme Geldenhuys wrote:
>
> > On Tue, Jul 29, 2008 at 5:50 PM, Daniël Mantione
> <[EMAIL PROTECTED]> wrote:
> >> Boost the usage of Unicode in FPC that would boost the usage of FPC
> >> itself. Unicode is one of the most demanded features (beside cross
> >> platform,
> >
Zitat von Michael Schnell <[EMAIL PROTECTED]>:
>
> > If this was true, Java would have taken that market already. There is
> > nothing new to that aspect of CIL, and specially with only one minor vendor
> > supporting it.
> >
> Basically you are right, but
> - In fact Java is very widely in use (
Graeme Geldenhuys schrieb:
On Tue, Jul 29, 2008 at 5:50 PM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
Boost the usage of Unicode in FPC that would boost the usage of FPC
itself. Unicode is one of the most demanded features (beside cross platform,
64bit support, etc) in Delphi since Delphi 7 (20
> Zitat von Michael Schnell <[EMAIL PROTECTED]>:
>
> > - AFAIK, CIL seems to improve some of the Java shortcomings
>
> I'm curious. Has someone evidence for that?
The CIL bytecode removes the typing needed only for interpreting, and thus
might be a bit more JIT friendly, and in general the requ
On Wed, Jul 30, 2008 at 10:48 AM, Michael Van Canneyt
<[EMAIL PROTECTED]> wrote:
>
> But we are few, we have day jobs, and we're not being paid for any of this.
I'm in the same boat. And I did offer to extend or start writing tests
cases to help implementation. I'm not a compiler developer (I don
> Graeme Geldenhuys schrieb:
> > beating Borland to the punch by about 7 years. FPC could have
> > attracted and converted more Delphi developers...
>
> Compatibility is the only way to attract Delphi developers. Just
> consider the kcl/fpgui vs. lcl case: kcl/fpgui started before the lcl
> and
On Wed, Jul 30, 2008 at 11:04 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
>
> We spent this time frame with making FPC multiplatform. Knowing what's
And I thank you again for it. :)
> delphi.non-technical is yellow press made by users for users.
What better place to find out what users thi
Marco van de Voort schrieb:
Read this and the reactions, and weep:
http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gst&q=voort+multicore#289008199451755a
I don't agree on the point that good mt support is a matter of t
On Wed, Jul 30, 2008 at 10:36 AM, Mattias Gärtner
<[EMAIL PROTECTED]> wrote:
>
> I wonder, what the next 'boost' feature of fpc is, that Delphi does not have
> yet: Automatic parallelization, language extensions for parallelization, fpc
> as
> scripting language, fpc as browser plugin, packages li
> Marco van de Voort schrieb:
> >
> > Read this and the reactions, and weep:
> >
> > http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gst&q=voort+multicore#289008199451755a
>
> I don't agree on the point that good mt suppo
I don't agree on the point that good mt support is a matter of the
framework. _Really_ good multithreading support is a matter and must
be a matter of the language as well and in several years and must be
as common as while or for loops. Currently, multithreaded programming
is like programmin
>> So.. questions are:
>> 1. trailing pathdelims, yes or no? (of course only if there's something to
>> return)
>
> What is the most logical according to you ?
For consistency purpose ( think of ExtractFileDir and ExtractFilePath
), why not define
* GetAppConfigDir : without pathdelim
* GetAppCo
On Wed, 30 Jul 2008, Graeme Geldenhuys wrote:
> On Wed, Jul 30, 2008 at 10:48 AM, Michael Van Canneyt
> <[EMAIL PROTECTED]> wrote:
> >
> > But we are few, we have day jobs, and we're not being paid for any of this.
>
> I'm in the same boat. And I did offer to extend or start writing tests
> cas
Dear Sirs ,
A discussion started on representation of Russian language
in FPC ( Free Pascal Compiler ) and continues toward about
the general design and future of FPC .
As a Computer ( let's say Scientist and/or Engineer )
I consider every idea exchanging as a good activity .
I want to pre
On Wed, 30 Jul 2008, Inoussa OUEDRAOGO wrote:
> >> So.. questions are:
> >> 1. trailing pathdelims, yes or no? (of course only if there's something to
> >> return)
> >
> > What is the most logical according to you ?
>
> For consistency purpose ( think of ExtractFileDir and ExtractFilePath
> ),
Hi Mehmet,
This is an extremely narrow vision, and I am afraid you are missing a lot of
approaches developed in the last few years. I advise you to visit
www.intel.com. They have a number of article of different compiler
approaches for multicore CPU utilization. They cover everything from
Mehmet Erol Sanliturk schrieb:
For that reason , I consider such a problem is in the domain of
operating systems .
FPC is able to generate such programs . Therefore in my opinion
it is not a vital problem to solve this problem "WITHIN" the FPC.
This is o
Dear Sirs ,
(A)
My ideas about dear Boian Mitov's views are
the following:
I do NOT think that my view is a narrow vision .
If you wonder how I am working I tell it :
Over my Desktop there are some html pages I prepared
myself filled a large number of company/organization
web page links .
S
Hi Mehmet,
Actually you are missing the point. The problem is not the operating system.
Lets assume for the moment the simple case of a 32 core system that
apparently will be available sometime next year (Dual octal cores with HT).
In case you are running multiple intensive processes you a
On Wed, Jul 30, 2008 at 1:27 PM, Michael Van Canneyt
<[EMAIL PROTECTED]> wrote:
>
> This is so, and is good, but compiler support for a new string type is
> of a different order...
That I can believe... and like somebody said before, it affects everything.
> Manpower and time are usually the pro
On Wed, 30 Jul 2008, Graeme Geldenhuys wrote:
> On Wed, Jul 30, 2008 at 1:27 PM, Michael Van Canneyt
> <[EMAIL PROTECTED]> wrote:
> >
> > This is so, and is good, but compiler support for a new string type is
> > of a different order...
>
> That I can believe... and like somebody said before, i
Op woensdag 30-07-2008 om 11:33 uur [tijdzone +0200], schreef Florian
Klaempfl:
> Marco van de Voort schrieb:
> >
> > Read this and the reactions, and weep:
> >
> > http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gst&q=voo
On Wed, Jul 30, 2008 at 5:01 PM, Joost van der Sluis <[EMAIL PROTECTED]> wrote:
> Just to test some ideas/opinions. Could something like this be usefull?
>
> Function DoSomething(const astring : string) : boolean; parallel;
> begin
> ..
> end
>
> So that the 'parallel' keywords means that if you ca
Hi Joost,
One option is each assembly instruction in the function to be actually
executed in a separated thread. This is one of the proposals of Intel. Of
course the compiler will have to packs the instructions the same way the
compilers for DSP chips, Transmeta Crusoe, and Itanium processo
Zitat von Joost van der Sluis <[EMAIL PROTECTED]>:
> Op woensdag 30-07-2008 om 11:33 uur [tijdzone +0200], schreef Florian
> Klaempfl:
> > Marco van de Voort schrieb:
> > >
> > > Read this and the reactions, and weep:
> > >
> > >
>
http://groups.google.com/group/borland.public.delphi.non-technical
Function DoSomething(const astring : string) : boolean; parallel;
begin
..
end
Why not stick to the "future" / "asyc" paradigm ? The fact that it
(supposedly) is originated from .NET does not make it a bad thing. And
if anybody already knows this paradigm from other language and thus does
Op woensdag 30-07-2008 om 04:42 uur [tijdzone -0700], schreef Mehmet
Erol Sanliturk:
> As a Computer ( let's say Scientist and/or Engineer )
> I consider every idea exchanging as a good activity .
Before we start to talk, it's important to make the difference between
the engineer and the scientis
This is only usefull if you have really, really, much cores. As Intel
indeed propagates? And how do those threads handle othe resources?
(memory?)
I think this is the far-away future. Intel is only pressing this because
they are scared that in a few years they can not improve PC speed as
fast as t
Op woensdag 30-07-2008 om 17:08 uur [tijdzone +0200], schreef Mattias
Gärtner:
>
> There is a wiki about that discussion:
> http://wiki.freepascal.org/OpenMP_support
Thanks for the link, very usefull. And I do see that (Graeme) that my
proposal is the same af that from Florian. I just hadn't rea
> One option is each assembly instruction in the function to be actually
> executed in a separated thread. This is one of the proposals of Intel. Of
> course the compiler will have to packs the instructions the same way the
> compilers for DSP chips, Transmeta Crusoe, and Itanium processors do t
Hi Joost,
Actually the trend started probably ~10-15 years ago with the DSP
processors. Then along came Transmeta, and the Itanium, then there ware the
GPUs including from NVidia, and there is PlayStation 3. They all use this
type of approach. The first massive multicore I am aware of is th
Yes. DSP, Crusoe and Itanium do it with execution units. The new wave
however is to do the same with cores. The idea is that a core can be thread
either as a stand alone core, or as execution unit, and to be better
utilized. This way you should in theory (According to Intel) get the best of
bot
As an alternate to whether we go along with open mp or whatever in the
current discussion, why don't we take notice of the previous email
discussion about fpc deciding things for itself & just do the very very
simplest (even noddy) thing that'll give people who aren't gurus the
ability to use the p
Hi John,
This is just a discussion. There is no real need for something like this at
the moment yet, and probably you should really just keep an eye on what
CodeGear and the other vendors are doing and follow their lead ;-) . It is
very likely we will start to see more and more of this stuf
> Eg only allow the parallel or async keyword (I personally do not care
> which) on an otherwise normal procedure and then another
> procedure/keyword isfinished(x)? which checks whether the 'parallel'
> procedure x has finished. With minimum (ie no) checking for whether the
> procedure uses global
Boian Mitov wrote:
among the processor architects. Intel already demonstrated 100+ core
processor last year. This year we expect the first 16 core processors to
hit the market ( 8 HT cores), and the direction is very clear. Any
compiler vendor, or developer, should at least be paying attention
Hmm... I thought the end users ware the ones always wanting faster stuff ;-)
. Like real time photo realistic 3D rendering ;-) . This means we the
developers press both the Processor vendors and the compiler developers to
get us the tools for that.
With best regards,
Boian Mitov
-
Actually if the compiler vendors don't do that it help us a bit. Our
libraries already have been redesigned for the 4.0 release to utilize vast
number of cores, and if the compilers don't have the multicore support, it
simply will give us competitive advantage ;-) . We are on the winnig side in
Op Wed, 30 Jul 2008, schreef Graeme Geldenhuys:
Does FPC have any any functions that work correctly with surrogate
pair used by UTF-16?
Likely, because I doubt FPC has routines, other than UTF-8 <-> UTF-16
conversion, that need to bother with surrogate pairs. I.e. the following
code is ful
Actually if I am not mistaken it was the MIPS that first shifted the
pipelining ordering from the processor into the compiler ;-) . You can't
even have a normal branch instruction in that bugger without another
instruction after it executing. It really gives me the itch when I have to
look into
[...]
> Because it's so simple we could then announce that we support
> parallelism eg in 2.2.4 or 2.4? Of course if a de facto standard did
> come along eg in Delphi or some other of the languages mentioned, we
> could take a view as to whether we'd support it.
Sorry, but adding parallelism into
Wasn't suggesting no sync - just trying to say let's keep it very simple so we
can do it quickly, but not, in words of mr E too simple! I yield to the gurus
re how simple it can be w/o it not being usable. J
[...]
> Because it's so simple we could then announce that we support
> parallelism eg
Marco van de Voort schrieb:
Eg only allow the parallel or async keyword (I personally do not care
which) on an otherwise normal procedure and then another
procedure/keyword isfinished(x)? which checks whether the 'parallel'
procedure x has finished. With minimum (ie no) checking for whether the
p
Vinzent Höfler schrieb:
[...]
Because it's so simple we could then announce that we support
parallelism eg in 2.2.4 or 2.4? Of course if a de facto standard did
come along eg in Delphi or some other of the languages mentioned, we
could take a view as to whether we'd support it.
Sorry, but add
> Marco van de Voort schrieb:
> > You could define a helper even for the first three lines.
>
> This is wrong. Asynchronous means that the procedure call is put into a
> queue and not immediatly handled if no thread is in the pool.
I know, but that is only a minor variation on the above scheme.
Op Wed, 30 Jul 2008, schreef Boian Mitov:
Hi Joost,
Actually the trend started probably ~10-15 years ago with the DSP processors.
Then along came Transmeta, and the Itanium, then there ware the GPUs
including from NVidia, and there is PlayStation 3. They all use this type of
approach. Th
Florian Klaempfl wrote:
This is wrong. Asynchronous means that the procedure call is put into
a queue and not immediatly handled if no thread is in the pool.
Further, your code doesn't handle efficient parameter passing.
Especially this needs compiler support.
_
On 30 Jul 2008, at 16:35, Boian Mitov wrote:
The future is not likely to be in faster systems, but in more cores.
This seems to be the consensus lately among the processor architects.
It's the consensus between the marketing departments of various
processor manufacturers, because that's wh
> On 30 Jul 2008, at 16:35, Boian Mitov wrote:
>
> > The future is not likely to be in faster systems, but in more cores.
> > This seems to be the consensus lately among the processor architects.
>
> It's the consensus between the marketing departments of various
> processor manufacturers, be
The good news for us, is that our customers do DSP, video and audio
processing, and our libraries are designed to utilize both single and
multicore systems, so we win in any case ;-) .
With best regards,
Boian Mitov
Mitov
56 matches
Mail list logo
