Am 16.09.2011 19:24, schrieb Luiz Americo Pereira Camara:
> with RawByteString (need the conversion - but how ?):
>
> function FileGetAttr(const FileName: RawByteString): Longint;
> begin
> // how to convert?
> // UnicodeString(FileName) -> will not work because dont know if is
> was a UTF
Am 17.09.2011 11:58, schrieb Martin:
>
> For lineinfo, I assume yes, since the unit has nothing to report on if not.
>
> heaptrc could live without, couldn't it?
Yes, in this case just add the heaptrc unit to the uses clause.
___
fpc-devel maillist -
Am 18.09.2011 10:54, schrieb Torsten:
> Hi,
>
> im starting with implementation of AVX (Intel/AMD) in fpc-assemblercode.
>
> I use in first step a external assembler (linux "as"). In this case, it
> is easy to use XMM-Register (max. 3 parameter) (only change the file
> "x86ins.dat", examble:
>
>
Am 30.09.2011 11:44, schrieb Henry Vermaak:
Hi list
Thinking more about the alignment problems on arm and elsewhere, I was
wondering how hard it would be to implement something like gcc's
-Wcast-align. Here's a description from the man page:
Warn whenever a pointer is cast such that the require
Am 30.09.2011 15:02, schrieb Joost van der Sluis:
Hi all,
For all those who are interested in new debug-features of fpc and gdb, I
have cross-compiled a gdb-executable for Windows.
It's based on the Fedora-16 branch from the Archer project. But I added
a few patches of my own, namely the patch
Am 03.10.2011 08:27, schrieb Alexander Klenin:
the following code:
{$mode objfpc}
var
a: Integer;
begin
a := a + 1;
asm nop end;
end.
generates (under -O2):
movlU_P$PROGRAM_A,%eax
incl%eax
movl%eax,U_P$PROGRAM_A
nop
instead of a single "incl
Am 03.10.2011 10:24, schrieb Jonas Maebe:
On 03 Oct 2011, at 10:14, Florian Klämpfl wrote:
FPC doesn't do any optimization in procedures containing inline
assembler.
It does.
Oops, I thought you changed this a while ago :)
___
fpc-devel mai
Am 03.10.2011 12:20, schrieb Felipe Monteiro de Carvalho:
On Mon, Oct 3, 2011 at 11:41 AM, wrote:
Please do not include this package yet.
I'd rather find a consensus on this now then to postpone yet again. I
have patches to merge about this and I have some time now which is
something which ca
Am 03.10.2011 13:23, schrieb Alexander Klenin:
This way, you can develop much faster, without the need to fight for
your changes,
Others call this fighting "review" and consider it as important part to
improve software quality.
___
fpc-devel mailli
Am 03.10.2011 15:32, schrieb Alexander Klenin:
On Mon, Oct 3, 2011 at 22:40, Florian Klämpfl wrote:
Am 03.10.2011 13:23, schrieb Alexander Klenin:
This way, you can develop much faster, without the need to fight for
your changes,
Others call this fighting "review" and cons
Am 03.10.2011 16:06, schrieb Alexander Klenin:
On Tue, Oct 4, 2011 at 00:42, Florian Klämpfl wrote:
Anyway, what I suggest is IMO a good compromise and should satisfy both
sides --
Felipe can continue development of his packages unobstucted,
while the quality of FPC will not suffer.
That&#
Am 03.10.2011 16:23, schrieb Joost van der Sluis:
On Sat, 2011-10-01 at 10:26 +0200, Florian Klämpfl wrote:
Am 30.09.2011 15:02, schrieb Joost van der Sluis:
Please test this gdb-version, and tell me about your experiences.
Especially Martin. ;)
Oh, you can download it here:
http
Am 15.10.2011 00:18, schrieb ik:
> Hello list,
>
> I have a project to develop app also for cellphones, and one of the
> environment will be Symbian (also iOS and Android).
> For using it, I need to better understand the status of the SymbianOS
> support using FPC.
> I remember that there was work
Am 15.11.2011 16:02, schrieb Jonas Maebe:
>
> On 15 Nov 2011, at 15:57, Felipe Monteiro de Carvalho wrote:
>
>> On Tue, Nov 15, 2011 at 2:51 PM,
>> wrote:
>>> So it's probably a lot easier to just IFDEF with a -DANDROID or
>>> so, and recompile the linux target specifically for android.
>>
>>
Am 15.11.2011 21:12, schrieb Jonas Maebe:
>
> On 15 Nov 2011, at 21:06, Florian Klämpfl wrote:
>
>> I dn't know if this is a good long term solution: I fear too much
>> duplication with having a seperate android target. I'd prefer an
>> FPC_ANDROID defin
Am 19.11.2011 11:31, schrieb Sergei Gorelkin:
> Hello,
>
> Is it possible to declare a (SSE friendly) record or array type, so that
> local variables of this type get aligned to e.g. 16 bytes? Target is
> x86_64 with aligned stack.
> The {$codealign localmin=16} directive seems to work, but it is
Am 20.11.2011 21:11, schrieb Jonas Maebe:
>
> On 20 Nov 2011, at 21:04, Florian Klämpfl wrote:
>
>> So declaring the type once with the right recordaligmax should be
>> sufficient?
>
> recordalignmax does not mean that a type will be aligned to a
> multiple of tha
Am 24.11.2011 14:59, schrieb Sergei Gorelkin:
> Hello,
>
> There are some differences between FPC and Delphi exception handling
> (working on SEH support, one would inevitably collect all of them):
>
> 1) Delphi uses EZeroDivide for floating-point division by zero, while
> FPC uses EDivByZero (th
Am 25.11.2011 19:00, schrieb Tomas Hajny:
> 2) The AMD docs (referenced from the URL above) explicitly mention the
> impacted CPU versions including Athlon64 (and the reference above mentions
> that it impacts both the x86 compatibility mode and the x86_64 native
> mode).
>
> 3) The problem is als
Am 27.11.2011 10:43, schrieb Hans-Peter Diettrich:
> On Win7 I encounter the following fatal error on "make clean all" of
> trunk (19693):
>
> D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe -f ./pp.exe ppc386.exe
> D:/lazarus931/fpc/2.4.2/bin/i386-win32/mv.exe: cannot remove
> `ppc386.exe': Permiss
Am 28.12.2011 15:55, schrieb Mattias Gaertner:
> Hi,
>
> What encoding does fpc use for file names in messages?
System encoding for 8 bit strings.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fp
Am 30.12.2011 02:00, schrieb Martin:
> Florian wrote at http://bugs.freepascal.org/view.php?id=20907
>> FPC has a good enough dfa, however it is only activated when compiling
>> with -Oodfa:
>>
>> c:\fpc\svn\compiler>fpc ..\tw20907 -vw -Oodfa
>
> Is that documented somewhere ? Is that production r
Am 30.12.2011 12:13, schrieb Sergei Gorelkin:
> 30.12.2011 14:42, Jonas Maebe пишет:
>>
>> On 30 Dec 2011, at 10:26, Florian Klämpfl wrote:
>>
>>> Beta. I'am not aware of any missing stuff, but it's mainly untested.
>>
>> I tried to activate by
Am 30.12.2011 12:47, schrieb Sergei Gorelkin:
> 30.12.2011 15:18, Florian Klämpfl пишет:
>>
>> I played with this yesterday and what about extended Initialize to
>> support unmanaged types? In case of an unmanaged type it just calls
>> fillchar.
>
> I was rath
Am 30.12.2011 21:19, schrieb Florian Klämpfl:
> Am 30.12.2011 12:47, schrieb Sergei Gorelkin:
>> 30.12.2011 15:18, Florian Klämpfl пишет:
>>>
>>> I played with this yesterday and what about extended Initialize to
>>> support unmanaged types? In case of an unman
Am 04.01.2012 19:24, schrieb Hans-Peter Diettrich:
> Skybuck Flying schrieb:
>>
>>
>> -Original Message- From: Hans-Peter Diettrich
>> Sent: Tuesday, January 03, 2012 14:56
>> To: FPC developers' list
>> Subject: Re: [fpc-devel] Pointer cache for fast class/pointer access.
>>
>> Skybuck Fly
Am 06.01.2012 11:16, schrieb Torsten:
> Hi,
>
> i don't understand the follow error message in 64-bit mode:
>
>
> assemblercode
>
> asm
> addpd xmm0, [EAX]
> end;
>
>
> I think this is a bug.
While in theory, it might be possible to write such code, I'am still
prefer the error of FPC: in 99.
Am 07.01.2012 06:33, schrieb Andrew Haines:
> Hi,
>
> I was trying to build a cross complier for mips-linux and met this error:
>
> make crossinstall PP=/usr/local/lib/fpc/2.6.0/ppcx64 OS_TARGET=linux
> CPU_TARGET=mipsel
>
> make[4]: Entering directory
> `/home/andrew/programming/fpc-2.6.0/p
Am 07.01.2012 15:19, schrieb Torsten:
> Hi,
>
> Am 07.01.2012 15:01, schrieb Sergei Gorelkin:
>> 07.01.2012 16:53, tgrundke пишет:
>>> Hi,
>>>
>>> i am working on the AVX-support for the fp-compiler.
>>>
>>> Some AVX-assembler instructions have 4 operant e.g.
>>>
>>>
>>> VBLENDVPD xmm1, xmm2, xmm3
Am 15.01.2012 16:26, schrieb Blaise Thorn:
> My question is: how the work should be organised? Should a separate SVN
> branch be created for this?
The best is to create an svn branch. See private mail.
___
fpc-devel maillist - fpc-devel@lists.freepasc
Am 15.01.2012 16:45, schrieb ik:
> On Sun, Jan 15, 2012 at 17:38, Florian Klämpfl <mailto:flor...@freepascal.org>> wrote:
>
> Am 15.01.2012 16:26, schrieb Blaise Thorn:
> > My question is: how the work should be organised? Should a
> separate SVN
>
Am 13.01.2012 22:46, schrieb Torsten:
> Hi,
>
> i need a little help.
>
>
> memory operand size:
>
> mem128mem256
> FPC DQWORD?
> nasm OWORDYWORD
> MASM XMMWORD YM
Am 18.01.2012 13:54, schrieb Gennadiy Poryev:
> Hi all,
>
> In my project (win32) I need to estimate the number of machine code bytes of
> a certain function.
What about using the map file?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
Am 22.01.2012 09:15, schrieb Sven Barth:
> On 21.01.2012 15:12, Florian Klaempfl wrote:
>> Am 21.01.2012 14:25, schrieb Sven Barth:
>>> On 20.01.2012 11:18, Skybuck Flying wrote:
Finally if you do believe prefetching is a good alternative to a
pointer
cache or simply want to try out
Main problem with MIPS is to get hands on a reasonable development
system (full fledged unix like Debian Linux, *BSD, CPU in the range of 1
GHz, 128 MB or more RAM, at least 1 GB of HD/SSD). Cross compiling is
possible of course, but it makes testing and bug fixing very tedious. If
ssh to such a sy
Am 03.02.2012 01:37, schrieb Nikolai Zhubr:
> I can set up ssh
> for any FPC developer(s) (though I'll need some time to fix cables etc
> then) Let me know.
It would be nice to get an account, currently I'am still busy with
fixing compilation issue but I'd expect first compiled programs within a
f
Am 11.03.2012 18:28, schrieb peter green:
>
>>> Are you saying that VFP registers are treated as multimedia registers
>>> and not as FPU registers? If so presumablly that mean I should be
>>> using LOC_MMREG and not LOC_FPUREG as the location for parameters and
>>> return values?
>>>
>>
>> Ye
Am 02.04.2012 06:50, schrieb Torsten:
> Hi,
>
> i need the size of a global variable (type record).
>
> local var: "operands[i].opr.localsym.getsize"
> global var: ???
>
> I can add a new field "globalsym" in the "TReference"-record ?
>
> What you say?
Why do you need the size? At this point e
Am 07.04.2012 18:19, schrieb Tomas Hajny:
> On 7 Apr 12, at 13:23, Jonas Maebe wrote:
>> On 07 Apr 2012, at 13:15, Martin Schreiber wrote:
>>
>>> Thanks, where can I get that "nm utility" for win32?
>>
>> Any distribution of the GNU binutils for win32 should include it. I don't
>> have Windows mys
Am 03.05.2012 10:49, schrieb fck...@freenet.de:
> Hi,
>
>
>
> my Intel/AMD assembler AVX 1 support is ready for testing.
>
>
>
> svn checkout http://svn.freepascal.org/svn/fpc/branches/tg74/avx ...
>
>
>
> build compiler: ./compiler/make cycle
>
>
>
> I have testing under Linux (32
I've created a new branch:
http://svn.freepascal.org/svn/fpc/branches/avx/
containing only the relevant changes and being rebased on current trunk
for easier reviewing.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/
Comments:
- I'am not happy with the new fields localvarsize and localconstoffset
in rautils.toprrec. Increasing the size of toprrec will probably
increase memory usage of the compiler, I also didn't get yet the use of
the fields: localsym and localsymofs should allow to figure out the same?
- What'
Am 03.05.2012 22:01, schrieb Torsten:
> Am 03.05.2012 18:24, schrieb Florian Klämpfl:
>> Am 03.05.2012 10:49, schrieb fck...@freenet.de:
>>> Hi,
>>>
>>>
>>>
>>> my Intel/AMD assembler AVX 1 support is ready for testing.
>>>
>>&
Am 25.05.2012 21:04, schrieb Jeppe Græsdal Johansen:
> Den 25-05-2012 13:54, Jonas Maebe skrev:
>>
>> Fuxin Zhang wrote on Fri, 25 May 2012:
>>
>>> And my progress and problems:
>>> I've got the source from subversion and tried to build it in ubuntu
>>> 11.10 x86-64 machine. With the following pa
Am 28.05.2012 10:38, schrieb tgrundke:
> Hi,
>
> can anyone merge the http://svn.freepascal.org/svn/fpc/branches/avx with
> my private branch http://svn.freepascal.org/svn/fpc/branches/tg74/avx
> ("compiler" and "tests" path) and
> the files:
> http://svn.freepascal.org/svn/fpc/branches/tg74/avx/
Am 08.06.2012 14:54, schrieb microc...@zoho.com:
> On Fri, 8 Jun 2012 17:15:51 +0800 (CST)
> "Fuxin Zhang" wrote:
>
>>
>>> I made a start at trying to get assembler and backend info into the
>>> Wiki, my intention was to at least have URLs for the various ABIs. I
>>> rather ground to a halt after
Am 09.06.2012 16:44, schrieb Mark Morgan Lloyd:
> Florian Klämpfl wrote:
>> Am 08.06.2012 14:54, schrieb microc...@zoho.com:
>>> On Fri, 8 Jun 2012 17:15:51 +0800 (CST)
>>> "Fuxin Zhang" wrote:
>>>
>>>>> I made a start at trying to get
Am 10.06.2012 08:15, schrieb Fuxin Zhang:
> Dear sirs,
>
> When trying to generate code debuggable by GDB, I meet a problem:
>
> * it seems mips C code will expect a frame pointer = sp after stack
> adjustment
> * but in cpupara.pas, when we create para info, we don't know yet the
> whole stack
Am 10.06.2012 19:18, schrieb Jonas Maebe:
>
> On 10 Jun 2012, at 18:50, Sergei Gorelkin wrote:
>
>> - after final frame size becomes known, fixup these instructions to
>> reference a real FP with adjusted offset. Or maybe not keep a
>> separate list of instructions, but instead just iterate the e
Am 14.07.2012 01:44, schrieb Jonas Maebe:
>
> Hi,
>
> I've implemented an optimization that reorders the instance fields of
> Delphi-style classes (and only of Delphi-style classes) to minimise
> memory gaps caused by alignment differences and odd sizes. The effect is
> the same as when you would
Am 21.07.2012 18:48, schrieb Martin:
> On 21/07/2012 16:55, Ivanko B wrote:
>> The problem now is that cracker classes can't be used in future anymore
>> because of the new class field ordering optimisation, so I dared to
>> ask.
>
>> So, is it possible to design the new feature in such way
Am 21.07.2012 20:47, schrieb Ivanko B:
> I don't see cracker classes as valid code.
> =
> Then the FPC team should eliminate the need in such crackers - via
> either disabling (via licencing, prisoning etc) the "impatient"
> [mainly because of impatient customers] non-mainstreams (non-L
or Martin Graeme to remember & explain
> all smallest details "what & when & why" and they can easily introduce
> bugs if fixing their code in a hurry. As they'll remember & fix their
> code to "without cracker" they'll be informing the FPC team to d
Am 22.07.2012 00:23, schrieb Ivanko B:
> Why should lazarus people have less chances to mess with private fields?
> =
> AFAIK, they haven't to use any crackers up to now and it is a normal
> way for the mainstream - where complier & IDE are maintained by same
> team
FPC and Lazarus are no
Am 22.07.2012 10:44, schrieb Ivanko B:
> A (global) compiler option "treat private as protected" might be
> another solution.
This is no solution but a hack.
>
> Same and less flexible than the {$ifdef nonLazarus} solution.
>
> What are the numbers of the issues worked around by the
Am 22.07.2012 23:02, schrieb Ivanko B:
> Then "friend" classes as C++ offers and wait for this feature were
> implemented before proceeding with the optimization :)
>
I never saw a C++ class pretending to be somebodies friend. iirc friend
classes must be defined in the class which elements shall
Am 28.07.2012 17:42, schrieb peter green:
> I am involved in a project called raspbian to produce a hard-float
> derivative of debian for the raspberry pi. Within this port we had
> problems with floating point exceptions while running the compiler.
> These problems were tracked down by masta (a fr
Am 04.08.2012 20:07, schrieb silvioprog:
> Hi,
>
> Please see:
>
> http://imagebin.org/223288
They are not unecessary but reference files created by gcc to test the
calling convention implementation of fpc.
___
fpc-devel maillist - fpc-devel@lists.f
Am 20.08.2012 10:26, schrieb Graeme Geldenhuys:
>
> So the BIG question remains: When will the FPC team sit down and hash
> out the details of implementing Unicode support? Please note, I'm not
> saying "implement it", just saying... "agree on how it should be
> implemented".
Fine with me: let's
Am 20.08.2012 16:25, schrieb Graeme Geldenhuys:
> On 20 August 2012 15:11, Florian Klämpfl wrote:
>> And who implements it? The public votes as well?
>
> Why are you complaining? You have your hobby projects (FPC etc.), and
> I have mine (fpGUI, tiOPF, OnGuard, MPP etc).
Am 20.08.2012 18:05, schrieb Graeme Geldenhuys:
> Hi,
>
> On 20 August 2012 15:43, Florian Klämpfl wrote:
>> Besides the resourcestrings I'am not aware of any unicodestring issues
>> in the *compiler*. If there are, please report them to the issue tracker.
>
>
Am 20.08.2012 20:27, schrieb Graeme Geldenhuys:
>
>>> * UnicodeString is always UTF-16 (so everything but Windows takes a
>>> conversion penalty)!
>>
>> A decision has been made and you are not happy with it. Fine. But before
>> you called the fpc team being in a deadlock?
>
> Many things by th
Am 22.08.2012 21:41, schrieb Graeme Geldenhuys:
> Also, how do I find out in SubVersion at what revision the 2.6.1 branch
> started?
2.6.1 did not start yet? It will be build from fixes_2_6. According to
the TortoiseSVN revision graph, fixes_2_6 has been branched from r18073.
>
> G.
>
>
> On
Am 13.09.2012 02:26, schrieb Michel Catudal:
> I would like to port fpc to the AVR32 uc3c devices. I need more details
> on the functions that need to be implemented.
Take a look at one of the other architectures like arm, fpc/compiler/arm
contains the arm specific compiler files.
___
Am 13.09.2012 21:38, schrieb Jeppe Græsdal Johansen:
> I have made a preliminary backend and RTL stub in
> branches/laksen/avr32new/
>
> Some of the large problems is that the load instructions allow
> non-aligned loads in the ld.w forms.
> This proves to introduce many
> strange problems,
Why i
Am 26.09.2012 13:27, schrieb Graeme Geldenhuys:
> On 2012-09-26 11:40, Marco van de Voort wrote:
>>
>> It means the interface will always be constref, and thus no ifdefing
>> in FPC
>> (if you don't support <2.6.0) will be necessary.
>
> For fpGUI, I only support the latest stable release of FPC,
Am 04.10.2012 19:42, schrieb Den Jean:
> On Thursday 04 October 2012 16:23:34 den.j...@telenet.be wrote:
>>> After the crosszipinstall, compiler/ppcarm (not installed, but in the
>>> source directory) is the native ARM compiler.
>>
>> I looked there with `file pp* `
>> How could I have missed that
Am 18.10.2012 13:24, schrieb Pierre Free Pascal:
> Are you resurrecting m68k port?
>
> Just a guess, of course...
Too late, but it would have been my guess as well. The tale misses only
the very sad part about the two children who never made it to life ;(
Am 26.10.2012 12:29, schrieb Mark Morgan Lloyd:
> (.text+0x68): undefined reference to `_fini'
> gdbver.pp(95,33) Error: Error while linking
> gdbver.pp(95,33) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> make[4]: *** [gdbver] Error 1
> make[4]: Leaving direc
Am 26.10.2012 22:51, schrieb Thomas Schatzl:
> Hi,
>
> On Fri, 2012-10-26 at 22:35 +0200, Tomas Hajny wrote:
>> On 26 Oct 12, at 19:46, Mark Morgan Lloyd wrote:
>>> I'm trying Thomas's suggestion first, pending Florian's comments.
>> .
>> .
>>
>> I'd say that Thomas' suggestion points to the sam
Am 26.10.2012 23:28, schrieb Mark Morgan Lloyd:
> Thomas Schatzl wrote:
>
>> Florian's suggestion is correct: debian is changing some paths beginning
>> with debian wheezy to improve multi-arch support.
>>
>> While on sparc this may not matter and maybe not needed, it's probably
>> done on all pla
Am 02.12.2012 19:50, schrieb Alexander Klenin:
> On Sun, Dec 2, 2012 at 9:47 PM, Tomas Hajny wrote:
>> On 2 Dec 12, at 16:45, Alexander Klenin wrote:
>>> I am not sure which options do you mean,
>>> I refer to the dll mentioned here: http://wiki.freepascal.org/gmp
>>
>> I meant multiple 2.6.2 inst
Am 06.12.2012 11:03, schrieb Alexander Klenin:
> On Thu, Dec 6, 2012 at 8:29 PM, Jonas Maebe wrote:
>> If a major problem is really the lack of standard support for
>> arbitrary-precision arithmetic, does that not mean that C and C++ are no
>> longer serious options either?
>
> Actually, this is
Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
> Hi,
>
> Any FPC developer willing to comment on the status of some of these
> issues (that have been years overdue)?
It narrows basically down to the fact that fpc lacks developers and
contributors, or do I miss something?
>
> Original
Am 18.12.2012 19:17, schrieb Vincent Snijders:
> 2012/12/18 Florian Klämpfl :
>> Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
>>> Hi,
>>>
>>> Any FPC developer willing to comment on the status of some of these
>>> issues (that have been years ove
Am 21.12.2012 09:23, schrieb Martin Schreiber:
> On Tuesday 18 December 2012 19:07:47 Florian Klämpfl wrote:
>> Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
>>> Hi,
>>>
>>> Any FPC developer willing to comment on the status of some of these
>>> is
Am 21.12.2012 12:58, schrieb Graeme Geldenhuys:
> On 21/12/12 10:15, Michael Van Canneyt wrote:
>>
>> It would be good to keep those facts in mind before ranting.
>
> I was simply bringing some of those questions (which I had too) to
> light. Unicode has been "under development" for many years, an
Am 22.12.2012 14:01, schrieb Graeme Geldenhuys:
> On 21/12/12 17:16, Florian Klämpfl wrote:
>>
>> The mission goal of FPC is: develop an open source pascal compiler
>> written in pascal in a community effort.
>
> You forgot the last bit "and be Delphi comp
Am 22.12.2012 11:23, schrieb Martin Schreiber:
> I propose to extend and render more precisely the mission goals of FPC and to
> concentrate the power on the defined goals.
>
And you think people will work on this defined goals instead of maybe
completely other projects? Or just fork FPC?
>
>
Am 23.12.2012 01:50, schrieb Graeme Geldenhuys:
> On 22/12/12 16:43, Marco van de Voort wrote:
>> I think you have a wrong idea on what the core list contains.
>
> LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
> mailing list.
>
>
>> I don't think direction on unicode (o
Am 26.12.2012 06:07, schrieb Martin Schreiber:
> Hi,
> Does any body work on a LLVM backend for Free Pascal?
> Thoughts?
The counterpart of what you want: tries to generate great code at any
cost while being maintainable and having a portable code generator.
__
Am 26.12.2012 05:42, schrieb Martin Schreiber:
> On Tuesday 25 December 2012 18:01:50 Florian Klaempfl wrote:
>> Am 25.12.2012 15:28, schrieb Mattias Gaertner:
>>> On Tue, 25 Dec 2012 12:55:41 +0100 (CET)
>>>
>>> mar...@stack.nl (Marco van de Voort) wrote:
[...]
The numbers Martin names (
Am 26.12.2012 13:17, schrieb Martin Schreiber:
> On Wednesday 26 December 2012 12:41:42 Sven Barth wrote:
>> On 26.12.2012 05:42, Martin Schreiber wrote:
Another thing would be an
fpc compiler daemon which stays in memory between compilations and keeps
also ppus loaded.
>>>
>>> AFAIK
Am 26.12.2012 11:43, schrieb Martin Schreiber:
> On Wednesday 26 December 2012 11:20:35 Florian Klämpfl wrote:
>> Am 26.12.2012 06:07, schrieb Martin Schreiber:
>>> Hi,
>>> Does any body work on a LLVM backend for Free Pascal?
>>> Thoughts?
>>
>> The
Am 30.12.2012 17:34, schrieb Michael Ring:
>
> UniqueString seems to be an Ansistring function and on fpc-pacal I found
> a post about a similar problem (Thread name is 'fpc 2.7.1 for
> arm-embedded'), the solution there was to add:
>
Thanks for the hint, I've fixed it in trunk.
___
Am 19.01.2013 12:18, schrieb Michael Ring:
> Today I found some time to research since when excactly arm-embedded
> does not compile anymore, I found that since revision 23325 compile does
> not work anymore, can anybody help, it seems that the problem itself is
> hidden somewhere else in code...
Am 24.01.2013 20:36, schrieb Alexander Klenin:
> That's debatable.
As long as there is only some few line idea, there cannot debated much.
Just an example: what happens with i if I start to delete from s during
the for loop?
___
fpc-devel maillist - fp
Am 24.01.2013 21:44, schrieb Mattias Gaertner:
> On Thu, 24 Jan 2013 21:30:23 +0100
> Florian Klämpfl wrote:
>
>> Am 24.01.2013 20:36, schrieb Alexander Klenin:
>>> That's debatable.
>>
>> As long as there is only some few line idea, there cannot debat
Am 24.01.2013 21:35, schrieb Alexander Klenin:
> On Fri, Jan 25, 2013 at 7:30 AM, Florian Klämpfl
> wrote:
>> Am 24.01.2013 20:36, schrieb Alexander Klenin:
>>> That's debatable.
>>
>> As long as there is only some few line idea, there cannot debat
Am 24.01.2013 22:26, schrieb Alexander Klenin:
> On Fri, Jan 25, 2013 at 7:56 AM, Florian Klämpfl
> wrote:
>>>> Just an example: what happens with i if I start to delete from s during
>>>> the for loop?
>>>
>>> Exactly the same thing as in the curr
Am 24.01.2013 21:41, schrieb Alexander Klenin:
> On Fri, Jan 25, 2013 at 7:34 AM, Marco van de Voort wrote:
>> In our previous episode, Florian Kl?mpfl said:
>>> As long as there is only some few line idea, there cannot debated much.
>>
>> http://www.freepascal.org/faq.var#extensionselect
>
> Yes
Am 25.01.2013 17:18, schrieb Alexander Klenin:
> On Fri, Jan 25, 2013 at 7:07 PM, Michael Van Canneyt
> wrote:
>> WITH EACH ADDITIONAL "FEATURE" WE ARE BUTCHERING PASCAL MORE AND MORE.
> Hm... Do not you think this is a bit of an overstatement?
>
>> There are plenty to choose from. He said maybe
Am 25.01.2013 18:17, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 3:30 AM, Florian Klämpfl
> wrote:
>>> "for-in-index" extension was actually planned by me as a prerequisite
>>> for fcl-stl work.
>>
>> Using indicies is against all principles
Am 25.01.2013 21:18, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 6:59 AM, Sven Barth
> wrote:
>>> What is "concrete code"? The code I provided only missed loop bodies.
>>> I can provide that too, but I do not think it will add anything to the
>>> discussion.
>>
>> I believe he wants to ha
Am 25.01.2013 22:44, schrieb Alexander Klenin:
> On Sat, Jan 26, 2013 at 5:30 AM, Florian Klämpfl
> wrote:
>> Where? Concrete code of a serious language! Not some "oh, yes, this
>> language has it and that as well"
>
> On Sat, Jan 26, 2013 at 7:34 AM, Florian K
Am 08.02.2013 16:02, schrieb Jonas Maebe:
>
> On 07 Feb 2013, at 16:52, Ewald wrote:
>
>> Altough I still
>> don't see how you can make these calls atomic then (without the
>> barrier)?
>
> On x86, it is impossible to perform an atomic access without a (partial)
> memory barrier that affects all
Am 09.02.2013 03:13, schrieb Vittorio Giovara:
> To do that we are using a tool
> named 'emscripten' which takes LLVM bytecode and generates Javascript,
> without affecting performance too much. Yes, we had to write a horribly
> hacked converter that took the small subset of Pascal used by Hedgewar
Am 10.02.2013 20:12, schrieb Vittorio Giovara:
>
> Well the existence of external tools is what has allowed technology
> to foster and advance,
In a perfect world, with unlimited cpu resources, yes.
> eg have some common grounds and entry
> points... Your (limited) example is not exactly perfec
Am 14.02.2013 23:44, schrieb Michael Ring:
> I have seen a lot of work on mpis platform in svn over the last weeks.
> Are there plans to create a mips-embedded target or is this strictly
> mips-linux?
It shouldn't be too hard, hardest task is probably to create appropriate
controller specific unit
Am 21.02.2013 19:43, schrieb silvioprog:
> Hello,
>
> I generates some PPUs in a version of FPC. I try to use it in other
> version of FPC, but it not compiles.
>
> So, can I disable the PPU version checking to I use my PPUs in any
> versions of FPC?
It won't help, we don't change the ppu versio
1 - 100 of 824 matches
Mail list logo
