Re: [fpc-devel] Sorting tests

On Thu, 24 Nov 2022 18:51:12 + "J. Gareth Moreton via fpc-devel" wrote: > Hi everyone, > > I just need to touch on the knowledge base.  What tests exist that test > the functionality of rtl/inc/sortbase.pp?  As Olly suggested, I'm > looking at creating Introsort for this unit as well, but

Re: [fpc-devel] Prototype optimisation... Sliding Window

On Fri, 25 Feb 2022 05:08:48 + "J. Gareth Moreton via fpc-devel" wrote: > Almost every source file in the compiler and the RTL shows some kind of > improvement.  A lot of them are just redundant pointer deallocations, so > this will help with cache misses and the like - that aside though,

Re: [fpc-devel] Assembler file option (-a)

Il giorno ven, 31/12/2021 alle 17.32 +0200, Christo Crause ha scritto: > On Fri, Dec 31, 2021 at 4:41 PM Marco Borsari via fpc-devel > wrote: > > Hi, > > on Linux with FPC 3.2.2 the executable size of programs compiled > > with > > fpc -On -a (tried with n 2

[fpc-devel] Assembler file option (-a)

Hi, on Linux with FPC 3.2.2 the executable size of programs compiled with fpc -On -a (tried with n 2 or 4) is smaller than when the assembler files are deleted (-a omitted). Does it is an expected behaviour? ___ fpc-devel maillist -

[fpc-devel] CursorOn/Off on Linux

Hi, I have always thought the procedures for the cursor appearance have intentionally left blank on Linux, but it is not so. In packages/rtl-console/src/unix/crt.pp they make use of ttySendStr, investigating a little I found that variables InCnt, InHead, InTail and OutCnt are not initialized,

Re: [fpc-devel] Capturing addresses

Il 10/11/2019 14:36, Jonas Maebe ha scritto: Hi, Does anyone know what the accepted/excepted behaviour is regarding the capture of addresses of var/out/const-by-address/constref parameters? For example: var g: longint; p: plongint; procedure test(var l: longint); begin p:=@l; end;

Re: [fpc-devel] Minor debate with ISO standard on case blocks

Il 31/07/2019 08:37, thaddy ha scritto: On 2019-07-31 08:26, Marco Borsari via fpc-devel wrote: What needs to be detected if all *used* labels are within the confines of the used ordinal, but a selector without label should throw an error. In the case of my patch it behaves like extended

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On Wed, 31 Jul 2019 01:26:23 +0200 Martok wrote: > Of course, if you wanted a run-time error you would need to insert a run-time > check, and 'some people' seemed to be hell-bent on saving these 2 cycles at > any > cost. > > The patch to switch from option a1) to a2) would be straightforward,

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On Tue, 30 Jul 2019 06:38:56 +0200 thaddy wrote: > According to what I found there is no smoking gun: I could not find any > implementation or reference from any reputable source that implements > the case statement in the way that is implemented in trunk: compile time > error when not all of

Re: [fpc-devel] Registers reloading

Il 18/07/2019 21:17, J. Gareth Moreton ha scritto: Hi Marco, That is actually one thing I've been researching myself. Currently the peephole optimiser doesn't have the facilities to detect if a register already contains a value that is being assigned to it, something I call the "Deep

[fpc-devel] Registers reloading

Hi all, does the compiler have the optimization to avoid reloading into a register of an address (or a value) whether it is already present? I ask this because of this code fragment compiled with the -O4 option: .Lj380: # Register eax allocated # [726] T := T-1; subw

Re: [fpc-devel] Unexpected behaviour of bit operators

On Fri, 17 May 2019 18:06:13 +0200 Ondrej Pokorny wrote: > On 17.05.2019 10:47, Marco Borsari via fpc-devel wrote: > > Does this is an effect of some multiplication overflow, or is it a bug? > > Both the bit operations and the arithmetic opretaions return integers as > res

Re: [fpc-devel] Unexpected behaviour of bit operators

On Fri, 17 May 2019 16:45:52 +0200 gabor wrote: > Can you provide c source code? > I'm not sure about this: > ...(a SHL 5+b SHR 2)... > Maybe it should look like this: > ((a SHL 5+b) SHR 2) > > Regards, Michał. Please look at https://burtleburtle.net/bob/hash/doobs.html for the Rotating

Re: [fpc-devel] Unexpected behaviour of bit operators

On Fri, 17 May 2019 14:36:52 +0200 Marco Borsari via fpc-devel wrote: > Thank you, your answer make it clear the nature of the problem, i.e. > operation size extension. > Anyway, if I understand correct, the masking as reported in the code > does not operate over the 16 bit limit

Re: [fpc-devel] Unexpected behaviour of bit operators

On Fri, 17 May 2019 11:55:55 +0100 "J. Gareth Moreton" wrote: > On a slightly different note, I would be careful about only using a > 16-bit hash, because the chance of a collision is only about 1 in 320 > (see "Birthday attack") > > Gareth aka. Kit Thank you, but in my use case collisions

Re: [fpc-devel] Unexpected behaviour of bit operators

On Fri, 17 May 2019 11:51:20 +0100 "J. Gareth Moreton" wrote: > One thing to be aware of is that the compiler will extend intermediate > expressions to the CPU size, so if the multiplication overflows into 32 > bits in h1 (which it does for the given values of a and b), it will > preserve

[fpc-devel] Unexpected behaviour of bit operators

In the code below program test; const n=12; s=1 shl n; var a,b,c,h1,h2:word; begin a:=77; b:=0; (*c:=(a XOR b)*(a SHL 5+b SHR 2);*) h1:=((a XOR b)*(a SHL 5+b SHR 2)) SHR (16-n); (*h1:=c SHR (16-n);*) h2:=((a XOR b)*(a SHL 5+b SHR 2)) AND ((s-1) SHL (16-n)) SHR (16-n); (*h2:=c AND ((s-1) SHL

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Il 01/01/2019 22:10, Martok ha scritto: - If a case statement on an ordinal does not contain labels for all values of the ordinal, and no else statement is given, raise a new warning (W6059). This is actually defined as an error in ISO7185 and a dynamic-violation in IEC10206. * in ISO mode,

Re: [fpc-devel] Case code pattern

Il 14/08/2018 12:37, Martok ha scritto: label label0,label1,label2,{...,}afterend; const table: array [lowestcaselabel..highestcaselabel] of CodePointer = (@label0, @label1, @label2{,...}); if (xhighestcaselabel) then goto @afterend; goto table[x]; label0: code; goto afterend; label1:

Re: [fpc-devel] Case code pattern

Il 14/08/2018 10:00, Martok ha scritto: array of index = array of pointers, sorry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Case code pattern

Il 14/08/2018 10:00, Martok ha scritto: What Kit said, but a correction: the threshold is not 50, it is 19. And what is generated is not technically a jump table, but a typed dispatch table. From what I can read from Wikipedia, every compound of the case is enclosed in a procedure (or in a

Re: [fpc-devel] Case code pattern

Il 13/08/2018 16:29, J. Gareth Moreton ha scritto: I haven't explored it too deeply myself, but from what I understand, a jump table is only generated if there are a large number of branches (over 50). If it's just a handful of branches, it simply subtracts values from the input corresponding

[fpc-devel] Case code pattern

Hello, I would need a clarification about the way the case statement is translated into assembler by FPC. When the list of alternatives is continous, does the compiler generate a jump table? And if yes, there is some conditions for which a fall-through is performed anyway? Thank you, Marco

Re: [fpc-devel] no rule to make target pass

On Wed, 9 Aug 2017 11:55:44 +0200 (CEST) mar...@stack.nl (Marco van de Voort) wrote: > I hadn't built FPC for a while on this machine, and the error I get this > morning flabbergasts me. (I also get this error when cycling when it should > start building the compiler after the RTL. I cleaned and

[fpc-devel] LineInfo

Does it is possible that the LineInfo trace (-gl option) are broken (no output) in 3.0.2 version on Linux (at least)? -- Marco Borsari ___ fpc-devel maillist - fpc-devel@lists.freepascal.org