Re: Which Delphi Version To Buy

Barry Kelly (CodeGear) wrote:
m. Th. wrote:

Barry Kelly (CodeGear) wrote:

[snip]

* Software implementation delivers a tremendous amount of flexibility.
Some examples: runtime metaprogramming (e.g. runtime code generation,
eval);
Given the fact that Delphi compiler is quick and small, do you see feasible having a runtime compiler/parser enabling what you describe above?

It's possible, but not really feasible starting from dcc32. I doubt it
would be worth the effort; reimplementation of various parts would be
more robust, maintainable, etc.

-- Barry

You have the source, you know :-) Our job is to give you ideas, to make you aware about our needs.

<Warning: draft ahead>
Speaking about this, it would be a very nice feature if we'll have something like a TPascalParser (the existing TParser is a little bit too low level for daily use imho), TKibitzParser & TCode classes, much more similar with a TStoredProcedure mechanism. Eg:

TCode = class(TComponent)
//basic functionality
property Source: TStringList;
function Compile: integer; //ErrorCode = 0 -> success
property Compiled: boolean;
procedure Run;

//InOuts
//perhaps the bellow ones to allow to have persistent instances
//like TField ones (see TDataSet for details)
property InArguments: TArgumentList;
property OutArguments: TArgumentList;

//multi-core stuff
property RunMode: TRunMode; //(rmSync, rmAsync)
property Priority: TThreadPriority; //obvious meaning
... //much more interesting stuff which I don't figure now
end;

....about 'various parts' and your previous talk about VM, imho perhaps is a better approach to 'mimic' the real machines (RM) not in their behavior (because then the VM will be useless, isn't?) but in their organization. Ie. to have multiple, specialized, VM for different tasks like we have different RM (read: GPU, north/south-bridges, sound/Lan controllers etc.) for different tasks.

Our goal, imho, is to make the things more natural, more closer to the way in which the human brain is working. For example the basic data types (string, ordinal, fpoint) processing in Delphi is (imho) sensibly superior to .NET's one exactly because is closer to the iron. OTOH, Delphi is lacking high level natural abstractions. For ex. futures as a natural way to go parallel:

myResult:= Fn1(x) + future high priority Fn2(y);

or async calls (in a hypothetical graphic file manager):

procedure TMainForm.btnChangeDirClick(Sender);
begin
//':' stands for if hMakeThumbs<>nil then stop the thread
hMakeThumbs:Stop; //perhaps you can implement this also?
lFiles:=BuildFileList(cMyDirectory);
nCrtFile:=0;
hLoadFile:=asynchronous high priority LoadFile(lFiles[nCrtFile]);
hMakeThumbs:=asynchronous low priority MakeThumbnails(cMyDirectory);
end;

....imho, there is a need to specify priority in the parallel programming as well as the percentage from total number of cores on which a certain task will be run (this is a very interesting thing especially when the number of cores will grow).

Well, for parallel programming I, for one, certainly feel the need of a VM (in the way in which you defined it) simply because the actual CPU architecture is far (imho) from the way in which humans deal with the reality which is parallel. Look at the game theory. The vast majority of the games you have to deal with /different/ characters doing /different/ actions (tasks) in parallel, responding each one to the stimuli which comes from the environment. Imho, that's why the Actor model (http://en.wikipedia.org/wiki/Actor_model) fits so well in parallel programming. Also, it seems that as a reaction to thread programming, we go now to parallel libraries, thing which is beneficial imho, but we tend to forget two properties from thread programming model which maps to the human way of thinking. Priority and worker(s) (read: CPU affinity). Imho, we should be able to say 'Do this faster, do this slower/when you have time' or 'Leave a worker (ie. core) for UI, 25% from "workers" for burst, small actions which need to be executed real-time, and the other ones use for the daily work. But perhaps I'm wrong. But now I remember your blog post about games... :-) (Yes, we *do* read your blogs, keep them coming)

hth,

m. Th.
.

Relevant Pages

  • Re: What Id Like to See in Delphi
    ... Delphi probably has been given new legs by the buyout. ... See desktop market at: ... Well, for parallel programming I, for one, certainly feel the need of a VM simply because the actual CPU architecture is far from the way in which humans deal with the reality which is parallel. ... with the compiler doing any housekeeping needed to let C++ ...
    (borland.public.delphi.non-technical)
  • Alternative Future of Delphi?
    ... relevant compiler or interpreter... ... No more intricate code generation required for a particular platform ... on the Delphi compiler side. ...
    (borland.public.delphi.non-technical)
  • Re: Version after Version
    ... merely because Delphi has no 64-bit compiler? ... >> targeted instructions and increasing the size of the cache to 32,000 ... >> That has nothing to do with the number of address lines on the CPU ...
    (alt.comp.lang.borland-delphi)
  • D7 revival? stirring the old pot + Delphi 64 suggestion
    ... The new compiler, but with the old IDE, the old help. ... You can check other areas of the site and poster stats, it's not that Delphi posters don't use .Net, it's just that they don't use Delphi for .Net work. ... As for the 64bit debugging, a CPU view debugger would be all that is really needed to get things started (this is for fastcode after all), no need for rich source-level debugging, inspectors, etc. early on. ... Validation could be two-ways: one in the fastcode challenge, another made via CodeGear private unit tests. ...
    (borland.public.delphi.non-technical)
  • Re: Compiler optimisation
    ... > Keep in mind that Delphi is one-pass compiler. ... > limits number of possible optimizations to ones that do not operate ...
    (borland.public.delphi.non-technical)