Re: [fpc-devel] Re: [FPC 0008690]: Add option/directive to ignore "Parameter X not used" hint
Flávio Etrusco wrote: On 4/14/07, Micha Nelissen <[EMAIL PROTECTED]> wrote: Perhaps it's an idea to not show this hint by default for methods declared in the published section of a class ? Most likely they are callbacks. Virtual methods could very probably join the dance ;-) In my experience, those are less troublesome; callbacks are usually more generically designed (what the callee may possibly need). Nevertheless, that could work well, as well :-). Regards, Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] BlackFin
Florian, Thanks a lot for discussing this ! Well, this depends how good one wants to make such a port ... In this case the (first version of the) port does not need to be very "good" (in the sense of creating optimized code), but of course the compiler needs to produce correct code that performs what had been expressed in Pascal. Do you think, it could be doable to create a not very optimized compiler ? I would join the team, but as I'm new to compiler construction, I don't think I can start that project by myself. The beauty of the Blackfin is that is extremely fast and offers an excellent price/performance relation. The chip I intend to use comes with two CPUs each clocked with 600 MHz. As the Blackfin can do single instruction / multiple data (e.g. four 8 bit adds or two 16 bit multiply/adds in a cycle ) and provides a zero-overhead looping mechanism the performance per CPU is (depending on the Application) like a 800 to 1500 MHz ARM. And the dual core chip costs about $20. Of course there are several smaller Blackfin chips. So IMHO this is an excellent processor for embedded use. And thus an interesting target for an FP port. As far as I have seen the BlackFin has two cores: an arm like risc core and a dsp. Not really. It's a DSP (predecessor of the Blackfin was the "Shark" DSP line) that has been enhanced by features necessary for standard CPUs. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] BlackFin
r2 = r1 + r3, r4 = dm(i0,m1); /* addition and memory access */ Yep. In my answer to Florian I forgot that (other than ARM) the Blackfin can do a calculation and a memory access in a single instruction cycle. That explains the much better performance even with standard (non-DSP-alike) tasks. r3 = r2 * r4, r1 = r2 + r4;/* multiplication and addition */ I did not know yet that it can do two independent 32 bit calculations and that it can do 32 bit multiplications. Anyway, even if only two 32 additions can be done in one instruction cycle this is a big chance for optimization. A totally different topic is the inherent parallel processing of a DSP. Usually they can utilize several processing units (+, *) and memories within a single cycle (e.g. see above). Instruction ordering and interleaving to utilize parallelism is tedious to do by hand and I think also challenging for a compiler. Maybe a first version could skip the great chances for optimization and just do a single operation per instruction cycle. It should be able to create a working compiler that way. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] BlackFin
Hi! Am Montag, den 16.04.2007, 11:57 +0200 schrieb Michael Schnell: > > r2 = r1 + r3, r4 = dm(i0,m1); /* addition and memory access */ > > > Yep. In my answer to Florian I forgot that (other than ARM) the Blackfin > can do a calculation and a memory access in a single instruction cycle. > That explains the much better performance even with standard > (non-DSP-alike) tasks. > > r3 = r2 * r4, r1 = r2 + r4;/* multiplication and addition */ > > > I did not know yet that it can do two independent 32 bit calculations > and that it can do 32 bit multiplications. Anyway, even if only two 32 > additions can be done in one instruction cycle this is a big chance for > optimization. The above code is based on an example program for some Shark or TigerShark DSP, so its likely that the BlackFin has other processing units. I've written the code just as an example for the algebraic style. You have to carefully study the structure of the CPU (i.e. processing units, busses, registers, address calculation, ...) to know what can be done in parallel. In the example I've looked at there was a line with 4-instructions-in-1-cycle: f10 = f2 * f4, f12 = f10 + f12, f2 = dm(i1,m2), f4 = pm(i8,m8); (ADSP-2106x). In modern CPUs the parallel utilization of busses and processing units is state of the art. The ressource allocation and parallelization is done on the fly during program execution by some smart logic inside the CPU. When a compiler does optimization for a certain CPU it anticipates this and sorts the instructions and registers approprately to gain a few percent more speed. The beauty of DSPs is that its in the hand of the compiler (or assembler coder) to do the full optimization. Bye Hansi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for heaptrc
> Pierre Muller schreef: >>> Attached patch add the same sanity check for the frame pointer in >>> TraceReAllocMem as >>> already is in TraceGetMem. It fixed crashes of Lazarus on win64 when >>> compiled with >>> heaptrc. >>> >>> Tested with fpc 2.1.3. fpc 2.3.1 is currently broken on win64, see mail >>> of >>> 8 April. >> I applied that to trunk, >> is it needed fro fixes_2_2 branch also? > > Yes, please. Merged in fixes_2_2 rev 7115. Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] BlackFin
Michael Schnell schrieb: > Florian, Thanks a lot for discussing this ! >> Well, this depends how good one wants to make such a port ... >> > In this case the (first version of the) port does not need to be very > "good" (in the sense of creating optimized code), but of course the > compiler needs to produce correct code that performs what had been > expressed in Pascal. > > Do you think, it could be doable to create a not very optimized compiler > ? I would join the team, but as I'm new to compiler construction, I > don't think I can start that project by myself. Coding the compiler part isn't that hard. I can do this, I did the initial arm port within a few weeks. The more annoying part is doing the debugging and find the things being broken. If you're interested, start a wiki page with some information where to get docs, tools, info about calling conventions etc. > > The beauty of the Blackfin is that is extremely fast and offers an > excellent price/performance relation. The chip I intend to use comes > with two CPUs each clocked with 600 MHz. As the Blackfin can do single > instruction / multiple data (e.g. four 8 bit adds or two 16 bit > multiply/adds in a cycle ) and provides a zero-overhead looping > mechanism the performance per CPU is (depending on the Application) like > a 800 to 1500 MHz ARM. And the dual core chip costs about $20. Of course > there are several smaller Blackfin chips. So IMHO this is an excellent > processor for embedded use. And thus an interesting target for an FP port. > > >> As far as I have seen the BlackFin has two cores: an arm like risc core >> and a dsp. >> > > Not really. It's a DSP (predecessor of the Blackfin was the "Shark" DSP > line) that has been enhanced by features necessary for standard CPUs. > > -Michael > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] round(variant) needs type cast
Hi,
I have the following program:
program project1;
{$mode objfpc}{$H+}
var
v: variant;
d: double;
begin
v := 3.3;
d := Round(v);
v := d;
end.
If I compile this on win32, then there is no problem. If I compile this
on win64, I get the following error:
project1.pas(11,8) Error: Can't determine which overloaded function to call
If change line 11 to
d := Round(round(v));
the error disappears.
Why does the same source compile on win32, but fail on win64?
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] round(variant) needs type cast
Vincent Snijders schreef:
Hi,
I have the following program:
program project1;
{$mode objfpc}{$H+}
var
v: variant;
d: double;
begin
v := 3.3;
d := Round(v);
v := d;
end.
If I compile this on win32, then there is no problem. If I compile this
on win64, I get the following error:
project1.pas(11,8) Error: Can't determine which overloaded function to call
If change line 11 to
d := Round(round(v));
I mean:
d := Round(double(v));
the error disappears.
Why does the same source compile on win32, but fail on win64?
Vincent
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
