Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2009-04

String cases development

26 messages · 11 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mike Denisenko

Hello everyone, I'm a student of FESU, Russia. I've started to develop a feature - string cases (Topic: Easiest way to "case" strings, http://www.lazarus.freepascal.org/pipermail/lazarus/2009-March/023369.html), and now some questions appear:

Existing method of parsing and generating assembly code doesn't process any constants but ordinal type, so the class holding case data, TCaseNode, contains labelinfo as object of TCaseLabel record.

And TCaseLabel contains two fields: _low and _high representing the low and high bounds of interval signed as case label. These fields are of TConstExprInt type, so if we want to process the string label we get a problem: how it's better to hold its value? Should we simply add two string-type fields to TCaseLabel, or it should be solved by creating a base class with some virtual procedures and refactoring all modules having procedures operating with this type?

Reply by email

Daniël Mantione
to Mike Denisenko

Op Sat, 18 Apr 2009, schreef Mike Denisenko:

Show quoted text 12 lines
Hello everyone, I'm a student of FESU, Russia. I've started to develop a feature - string cases (Topic: Easiest way to "case" strings, http://www.lazarus.freepascal.org/pipermail/lazarus/2009-March/023369.html), and now some questions appear: Existing method of parsing and generating assembly code doesn't process any constants but ordinal type, so the class holding case data, TCaseNode, contains labelinfo as object of TCaseLabel record. And TCaseLabel contains two fields: _low and _high representing the low and high bounds of interval signed as case label. These fields are of TConstExprInt type, so if we want to process the string label we get a problem: how it's better to hold its value? Should we simply add two string-type fields to TCaseLabel, or it should be solved by creating a base class with some virtual procedures and refactoring all modules having procedures operating with this type?

I am fine converting Tcaselabel into a variant record that takes a Pstring field. A new class is not a good idea, since we already have classes for this purpose: Tnode and descendends, a string constant can be represented by a Tstringconstnode. Tnode should be the most flexible since it allows you to handle all types of contants (and non constants if necessary).

Probably the parser already creates a Tnode tree, does constant expression evalutation, and then creates a Tcaselabel with the evaluated constant.

I wrote this case-label code about 10 years ago, it has a fundamental flaw: There is a worst case with quadratic time blowup, if you create a specially crafted case statement in the code, you can keep the compiler busy for a very long time. On the other hand, this has never been a problem in the lifetime of the compiler.

Daniël

Reply by email

Alexander Klenin
to Mike Denisenko: Hello everyone, I'm a student of FESU, Russia. I've started to develop a feature - string…

2009/4/18 Mike Denisenko :

Hello everyone, I'm a student of FESU, Russia. I've started to develop a feature - string cases

Mike is my student, and he is doing this project as a course work at our university
(http://imcs.dvgu.ru/works/work?wid=7539 , russian only). So I will try to oversee and help him.
He plans to work using Mercurial mirror of the FPC repository, and submit patches
either one-by-one or in batches via Mantis.

We have another question: is the structure and workings of FPC test suite documented somewhere?
Cursory search resulted in a few test cases related to 'case' statement in various locations.
Where should new tests for string 'case' be added?

Alexander S. Klenin

Reply by email

Florian Klaempfl
to Mike Denisenko: Hello everyone, I'm a student of FESU, Russia. I've started to develop a feature - string…
Show quoted text 9 lines
Hello everyone, I'm a student of FESU, Russia. I've started to develop a feature - string cases (Topic: Easiest way to "case" strings, http://www.lazarus.freepascal.org/pipermail/lazarus/2009-March/023369.html), and now some questions appear: Existing method of parsing and generating assembly code doesn't process any constants but ordinal type, so the class holding case data, TCaseNode, contains labelinfo as object of TCaseLabel record.

For string case nodes, I see no need to generate assembler directly. It should be sufficient to generate an appropriate node tree so the whole implementation is portable

Show quoted text 8 lines
And TCaseLabel contains two fields: _low and _high representing the low and high bounds of interval signed as case label. These fields are of TConstExprInt type, so if we want to process the string label we get a problem: how it's better to hold its value? Should we simply add two string-type fields to TCaseLabel, or it should be solved by creating a base class with some virtual procedures and refactoring all modules having procedures operating with this type?

Make TCaseLabel a variant record.

Reply by email

Mr. Moonlight - 1

I have a question about adding error messages to msgtxt.inc. As I've understood, there's an array of strings each 240 symbs long. So shall I add a string 240 characters long only, or there's another way?

Reply by email

Michael V. Denisenko

I have a question about adding error messages to msgtxt.inc. As I've understood, there's an array of strings each 240 symbs long. So shall I add a string 240 characters long only, or there's another way?

Reply by email

Jonas Maebe
to Michael V. Denisenko
Michael V. Denisenko wrote
I have a question about adding error messages to msgtxt.inc. As I've understood, there's an array of strings each 240 symbs long. So shall I add a string 240 characters long only, or there's another way?

You have to add the message to compiler/msg/errore.msg (including a description for the manual, like for the other messages). When you compile the compiler afterwards using the makefile (or use "make msg"), the msgtxt.inc and msgidx.inc files will be regenerated.

Jonas

Reply by email

Michael V. Denisenko
to Jonas Maebe

Здравствуйте, Jonas.

Вы писали 24 апреля 2009 г., 22:30:55:

Show quoted text 6 lines
On 24 Apr 2009, at 13:24, Michael V. Denisenko wrote: > I have a question about adding error messages to msgtxt.inc. > As I've understood, there's an array of strings each 240 symbs long. > So shall I add a string 240 characters long only, or there's another > way?

I've got a problem trying to move fpc_shortstr_compare parameters to the registers EAX and EDX.
The command 'getintregister', as I understood, returns some register which just satisfies a size-condition.

How to get a proper register, for example, EDX? Is there any special command?

Michael

Reply by email

Florian Klaempfl
to Michael V. Denisenko
Show quoted text 12 lines
Здравствуйте, Jonas. Вы писали 24 апреля 2009 г., 22:30:55: > On 24 Apr 2009, at 13:24, Michael V. Denisenko wrote: >> I have a question about adding error messages to msgtxt.inc. >> As I've understood, there's an array of strings each 240 symbs long. >> So shall I add a string 240 characters long only, or there's another >> way? I've got a problem trying to move fpc_shortstr_compare parameters to the registers EAX and EDX.

This should not be needed. Please try to generate only a tnode tree using existing nodes, else you need to implement all the secondpass code for at least 6 architectures.

Reply by email

Jonas Maebe
to Michael V. Denisenko: Здравствуйте, Jonas. Вы писали 24 апреля 2009 г., 22:30:55:…
Michael V. Denisenko wrote 8 lines
Здравствуйте, Jonas. I've got a problem trying to move fpc_shortstr_compare parameters to the registers EAX and EDX. The command 'getintregister', as I understood, returns some register which just satisfies a size-condition. How to get a proper register, for example, EDX? Is there any special command?

There is paramanager.getintparaloc(), but you should try doing as much as possible at the node tree level rather than at the assembler level (especially calls). You can use caddnode.create(equaln,x,y) to create a comparison node, cstringconstnode.create() to create a string constant node, etc. The addnode will automatically select the proper comparison routine (shortstring, ansistring, widestring, unicodestring, <any future kind of string>) and insert necessary type conversions.

Jonas

Reply by email

Vincent Snijders
to Michael Schnell
Michael Schnell wrote 6 lines
> implement all the secondpass code > for at least 6 architectures. Which are the currently supported or planned archs ? The Wiki main page only shows four X86/64 is obviously missing.

At least i386, x86_64, powerpc, powerpc64, arm, sparc had a 2.2.4 release.

Vincent

Reply by email

Tomas Hajny
Vincent Snijders wrote 9 lines
Michael Schnell schreef: > >> implement all the secondpass code >> for at least 6 architectures. > Which are the currently supported or planned archs ? The Wiki main page > only shows four X86/64 is obviously missing. > At least i386, x86_64, powerpc, powerpc64, arm, sparc had a 2.2.4 release.

Plus m68k is occassionally still being worked on by Charlie...

Tomas

Reply by email

Tomas Hajny
to Michael Schnell
Michael Schnell wrote
Perhaps the Wiki main page should be updated by one of the "powers".

I'm confused - which URL do you refer to? I don't see any particular information about platforms on http://wiki.freepascal.org. The information about supported platforms is available on http://wiki.freepascal.org/Platform_list, but both this page and the general WWW page (http://www.freepascal.org) seem to contain the complete list of supported CPUs. What did I miss there?

Tomas

Reply by email

Michael V. Denisenko

A question appeared when I tried to find a method of generating case-expression just once, not for every comparison. Is it optimal to try to add for every case-structure (and do...while, by the way) a temporary variable where we may hold the value of case-expression?

Reply by email

Daniël Mantione
to Michael V. Denisenko

Op Tue, 5 May 2009, schreef Michael V. Denisenko:

A question appeared when I tried to find a method of generating case-expression just once, not for every comparison. Is it optimal to try to add for every case-structure (and do...while, by the way) a temporary variable where we may hold the value of case-expression?

Yes, but it only if the variable part of the case expression is complex, i.e. not a simple loadn or perhaps subscriptn of a simple loadn.

Daniël

Reply by email

Tomas Hajny
to Michael Schnell: Sorry, it's not a Wiki page but the "free pascal" main page: http://www.freepascal.org/…
Michael Schnell wrote 7 lines
Tomas Hajny wrote: >> Perhaps the Wiki main page should be updated by one of the "powers". > > I'm confused - which URL do you refer to? Sorry, it's not a Wiki page but the "free pascal" main page: http://www.freepascal.org/

As mentioned in my previous e-mail, that page contains the complete list too - see the first paragraph: 'It is available for different processors: Intel x86, Amd64/x86_64, PowerPC, PowerPC64, Sparc, ARM.'. I suspect that you were confused by the section 'Requirements', that one indeed only contains information for 4 architectures and in fact just a limited subset of platforms. Nevertheless, this is something different from the list of supported CPUs.

Tomas

Reply by email

Peter Vreman
Show quoted text 11 lines
Op Tue, 5 May 2009, schreef Michael V. Denisenko: > A question appeared when I tried to find a method of generating > case-expression just once, not for every comparison. Is it optimal to > try to add for every case-structure (and do...while, by the way) a > temporary variable where we may hold the value of case-expression? Yes, but it only if the variable part of the case expression is complex, i.e. not a simple loadn or perhaps subscriptn of a simple loadn.

In pstatmnt.pas _with_statement() function there is code that also already provides the same functionality for the with statement. This code can be generalized and reused.

Peter

Reply by email