Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[J. Gareth Moreton]

I'm a bit late to the party again, but the example of an OpenGL shader 
has won me over, since game design is one thing I enjoy doing.  I guess 
I'm still a bit unsure how leading and trailing whitespace should be 
handled, but as long as it's well-documented, I think I'll be happy!


Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing 
alongside it, because things like shaders are programs in themselves and 
may have to be tested in a third-party application, so including the 
file directly rather than copying and pasting its contents would be much 
safer if changes need to be made.


Gareth aka. Kit

P.S. Granted, depending on how secure I want to be, I may still have the 
shader stored in an external file that's loaded at run-time, possibly in 
an encrypted archive (mostly to help make wall hacks etc. harder to 
develop), but that's just me.



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[J. Gareth Moreton]

On an extra note, the assembly language produced is not yet optimal, so 
it may end up that an x86-specific implementation will be beneficial.  
TIsNode contains a virtual method named "DoVariableEnumCheck" that would 
allow such an extension, coupled with returning "nil" that would defer 
code generation to "pass_generate_code" (allowing this, but not 
overriding "pass_generate_code", will trigger an internal error, because 
the 'is' node normally never allows it to be called).  Nevertheless, 
even if that is a no-go, it's making me a little excited to see if I can 
find new peephole optimisations to implement.  But until my old x86_64 
overhaul is accepted, rejected or reworked (at least to make it 
successfully merge), I can't really make any new additions yet.


Gareth aka. Kit

P.S. One optimisation I would like to suggest across all platforms, if 
at all possible, is to defer register allocations until after the first 
peephole optimisation stage, because I see sequences like this on i386 
when working with Int64's (this particular sequence sign-extends from 
LongInt to Int64):


mov %reg1,%reg2
sar $31,%reg2

This fills %reg2 with all 0s or all 1s depending on if the sign bit is 
set in %reg1.  However, if the registers are still virtual, it may be 
possible to evaluate nearby code and request a preference for %eax for 
%reg1 and %edx for %reg2 (certain operations like "mul", "div" or 
function parameters require the use of %eax and %edx specifically) - 
that way, the sequence can be collapsed into a single call (and a single 
byte in size) to "cdq".



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[J. Gareth Moreton]

Uploaded the latest patch (AS-IS-enum-07.patch) over here 
 and also a test project 
that evaluates the "is" operator between different ordinal types.


Following the advice of Jonas and Florian, I've removed my x86-specific 
code for now.


Gareth aka. Kit



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Ben Grasset]

Neat bit of trivia:

Multi line strings even work properly with Ryan's (Ryan Joseph that is)
very-cool-but-not-yet-merged-to-trunk
 generic constants patch.

With a build of FPC that includes both, you can do some really interesting
stuff:

program FunWithCurrentlyUnofficialLanguageFeatures;

{$mode ObjFPC}
{$modeswitch AdvancedRecords}
{$modeswitch MultiLineStrings}

type
  generic Tripler = record
const Result = S + S + S;
  end;

begin
  Write(
specialize Tripler<`
  A
  B
  C
  D
`>.Result
  );
end.

The above program printing, as you might expect:

  A
  B
  C
  D

  A
  B
  C
  D

  A
  B
  C
  D

Can't do that in Delphi!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[J. Gareth Moreton]

Oh right!  In that case, I can upload the code now... well, after I 
finish testing everything!  (I'll keep my platform-specific code in a 
personal branch though in case it doesn't work).


I have seen once source of inefficiency in the compiled assembly 
language and that's something akin to this (the code is to assign the 
result of a condition to a Boolean variable - for example, "Result := 
Value is TEnum;")


  cmpl   $##, %reg
  jnbe   @Lbl
  xorb   %al, %al
  jmp    @Done
@lbl:
  movb   $1, %al
@Done:

(Presumably the xorb %al,%al line was originally movb $0,%al before the 
post-peephole stage converted it) It might be this way because there was 
something else in between that was optimised out, but this could be 
optimised to:


  CMP    $##, %reg
  SETNBE %al

Note that there is one shortcoming that I've discovered while writing a 
test, and that you can't yet use as/is in a generic function - that is, 
if you have something akin to this:


generic function(Value: T1): Boolean;
begin
  Result := T1 is T2;
end;

It will fail, saying that a class type is expected where T2 is 
specified. I'll open a separate issue for this once the first patches 
are accepted and cleaned up.


Gareth aka. Kit

On 07/07/2019 20:07, Jonas Maebe wrote:

On 07/07/2019 07:33, J. Gareth Moreton wrote:

Maybe I'm missing something painfully
obvious here. Can I request an example
where such an invalid value/undefined
behaviour crops up in bitpacked records so
I can see what's going on? Logic dictates
that the number of bits required to store
an enum in that arrangement is equal to
the index of the highest element,

That is correct, but the discussion revolves about storing elements that
are larger than that the highest or smaller than the lowest element. In
that case, bits gets lost when storing them in bitpacked versions.


On 07/07/2019 19:36, J. Gareth Moreton wrote:

Additionally, I'm putting in an implementation specific to x86 because I
can take advantage of its ALU design to do the range check in as few as
2 instructions (a comparison and either a conditional jump or a SETcc
instruction).  If the range exceeds the CPU size though, then it falls
back to the node-level, platform-agnostic method.

That is not necessary. The compiler can do that trick itself (in a
CPU-independent way). Before yesterday, it could only do it with
unsigned ranges, but since yesterday it can also do it for signed ranges.

It can't yet inline the fpc_is/as_enum because it calls an
implementation-only procedure of the system unit, but I'm working on
solving that as well.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Jonas Maebe]

On 07/07/2019 07:33, J. Gareth Moreton wrote:
> Maybe I'm missing something painfully 
> obvious here. Can I request an example 
> where such an invalid value/undefined 
> behaviour crops up in bitpacked records so 
> I can see what's going on? Logic dictates 
> that the number of bits required to store 
> an enum in that arrangement is equal to 
> the index of the highest element,

That is correct, but the discussion revolves about storing elements that
are larger than that the highest or smaller than the lowest element. In
that case, bits gets lost when storing them in bitpacked versions.


On 07/07/2019 19:36, J. Gareth Moreton wrote:
> Additionally, I'm putting in an implementation specific to x86 because I
> can take advantage of its ALU design to do the range check in as few as
> 2 instructions (a comparison and either a conditional jump or a SETcc
> instruction).  If the range exceeds the CPU size though, then it falls
> back to the node-level, platform-agnostic method.

That is not necessary. The compiler can do that trick itself (in a
CPU-independent way). Before yesterday, it could only do it with
unsigned ranges, but since yesterday it can also do it for signed ranges.

It can't yet inline the fpc_is/as_enum because it calls an
implementation-only procedure of the system unit, but I'm working on
solving that as well.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[J. Gareth Moreton]

Most of it is node-level.  Ondrej's method was to use an inlined 
compilerproc to do the range check, but the parameters are of type 
SizeInt, which causes problems if the range to check against is of size 
Int64 or, worse, QWord.  It may be that after some refactoring, the 
nodes for such an inlined procedure can be inserted directly rather than 
just inserting a procedure call.


Additionally, I'm putting in an implementation specific to x86 because I 
can take advantage of its ALU design to do the range check in as few as 
2 instructions (a comparison and either a conditional jump or a SETcc 
instruction).  If the range exceeds the CPU size though, then it falls 
back to the node-level, platform-agnostic method.


It's probably better to simply show the code for scrutiny once I get it 
ready, rather than try to explain myself.  Nevertheless, there may be 
some peephole optimisations that are to be added, but I haven't worked 
on that in a while due to my overhaul that needs updating so it at least 
merges with the latest trunk and doesn't undo a load of more recent changes.


Gareth aka. Kit

On 07/07/2019 09:24, Florian Klämpfl wrote:

Am 07.07.2019 um 07:33 schrieb J. Gareth Moreton:

Maybe I'm missing something painfully
obvious here. Can I request an example
where such an invalid value/undefined
behaviour crops up in bitpacked records so
I can see what's going on? Logic dictates
that the number of bits required to store
an enum in that arrangement is equal to
the index of the highest element, although
that's without looking at the source code
and doesn't account for elements that have
assigned negative values.

In the meantime, I'm working on making
"as" and "is" work with ordinal types as
well as enumerations, although currently
some headaches occur if the right-hand
side is larger than the CPU word size
(e.g. Int64 on i386). I'll upload the
patch to the issue once it's working
properly.

I strongly recommend to add these changes at node level, then you do not have 
to fiddle with the alu sizes of different
CPUs.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Ben Grasset]

On Sun, Jul 7, 2019 at 4:20 AM Tomas Hajny  wrote:

> - snip -
>

These are all good points! Thanks for the feedback.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[wkitty42]

On 7/7/19 10:43 AM, Marģers . via fpc-devel wrote:

Well, trunk i use still has no string quote
character " .
Maybe it's time add that too while Ben Grasset on
implementing multi line strings? Just kidding...



hahahaha! i guess my memory is worse than i thought! :rotflmao:

truth be known, i've been doing a lot of bash, perl, javascript, python3, and 
other similar coding recently... when i first wrote my message, i had put printf 
instead of writeln! hahaha! maybe it is just a lack of sleep, though? that or 
lack of c0ffee :)



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Marģers . via fpc-devel]

 

- Reply to message -
From:  
To:  
> On 7/6/19 4:50 PM, wkitt...@windstream.net wrote:

> >   writeln("MultiLine1= '",MultiLine1,"'");
> >   writeln("MultiLine2= '",MultiLine2,"'");

> (* i forgot to do the line for MultiLine3 *)
> writeln("MultiLine3= '",MultiLine3,"'");
> (* that's what happens when you write directly
> in the email editor without testing *)

Well, trunk i use still has no string quote
character " .
Maybe it's time add that too while Ben Grasset on
implementing multi line strings? Just kidding...

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[wkitty42]

On 7/6/19 4:50 PM, wkitt...@windstream.net wrote:

const MultiLine =
`Sentence one.
Another sentence.
A third sentence.
A fourth sentence.
A fifth sentence.`;


procedure foo
   procedure bar
     const MultiLine1 =
   `Sentence one.
    Another sentence.
    A third sentence.
    A fourth sentence.
    A fifth sentence.`;
   MultiLine2 = `Sentence one.
     Another sentence.
     A third sentence.
     A fourth sentence.
     A fifth sentence.`;
   MultiLine3 = `Sentence one.
Another sentence.
A third sentence.
A fourth sentence.
A fifth sentence.`;
     begin
   writeln("MultiLine1= '",MultiLine1,"'");
   writeln("MultiLine2= '",MultiLine2,"'");


(* i forgot to do the line for MultiLine3 *)
writeln("MultiLine3= '",MultiLine3,"'");
(* that's what happens when you write directly
   in the email editor without testing *)


     end;
   begin
     bar;
   end;
end;



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Florian Klämpfl]

Am 07.07.2019 um 07:33 schrieb J. Gareth Moreton:
> Maybe I'm missing something painfully 
> obvious here. Can I request an example 
> where such an invalid value/undefined 
> behaviour crops up in bitpacked records so 
> I can see what's going on? Logic dictates 
> that the number of bits required to store 
> an enum in that arrangement is equal to 
> the index of the highest element, although 
> that's without looking at the source code 
> and doesn't account for elements that have 
> assigned negative values.
> 
> In the meantime, I'm working on making 
> "as" and "is" work with ordinal types as 
> well as enumerations, although currently 
> some headaches occur if the right-hand 
> side is larger than the CPU word size 
> (e.g. Int64 on i386). I'll upload the 
> patch to the issue once it's working 
> properly.

I strongly recommend to add these changes at node level, then you do not have 
to fiddle with the alu sizes of different
CPUs.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Tomas Hajny]

On 2019-07-06 23:37, Ben Grasset wrote:
On Sat, Jul 6, 2019 at 5:17 PM Ben Grasset  
wrote:


You cannot, in my opinion at least, reasonably expect something like 
this
to *ignore* all indentation and still function in any logical way. 
That the
leading whitespace is taken at "face value" is a large part of what 
makes

it useful for anything at all.



That said: it may, eventually, be possible for me to add an additional
directive taking a number that indicates how many spaces to *remove* 
from

the beginning of a line (but never add.)

 .
 .

Personally, I don't think that such a directive is worth the effort, 
because _if_ any indentation should be supported for these strings, it 
would only make sense to indent them to the same level as the 
surrounding code (which may differ obviously). From this point of view, 
a directive allowing to trim leading whitespaces from them would make 
more sense (but even that is not that much necessary as far as I can 
tell).


BTW, should you consider creating such a directive, it should probably 
allow something like the following (to provide means to have a leading 
space where necessary):


{$MULTILINESTRINGS INDENTED} (* Just invented ;-) *)
const
  MultilineString = `Line 1
 Line 2
 `#32`Line 3 with one leading space`;
WriteLn (MultilineString);

... resulting in:

Line 1
Line 2
 Line 3 with one leading space

Tomas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel