Freepascal: Unterschied zwischen den Versionen
Root (Diskussion | Beiträge) |
Root (Diskussion | Beiträge) |
||
Zeile 79: | Zeile 79: | ||
* fpc\compiler\x86_64\nx64set.pas Line 63 ff | * fpc\compiler\x86_64\nx64set.pas Line 63 ff | ||
* Optimierung nur bei -Os, (=size), ich halte aber auch "speed" für ein Argument | |||
Es ist eine Optimierung beim Freepascal Case Statement möglich, wenn z.B. anhand eines enum-Types unterschieden werden soll: | Es ist eine Optimierung beim Freepascal Case Statement möglich, wenn z.B. anhand eines enum-Types unterschieden werden soll: | ||
* die Optimierung für bei einer Hohen Granularität sind keiner erhöhten Code Grösse | |||
** Beispiel, ein Range verschlechtert die Granularität 99..110 würde 12 JMP Table Einträge erzeugen! | |||
* bei wesentlichen Lücken im case Statement würden viele "NOP"-Einträge entstehen | |||
** case n of 0: 20: else end; es würden für 1..19 "Lücken" entstehen, die alle nach "else" springen | |||
* Linear-Verschiebung, Normalisierung: case n -2: -1: 0: 1: 2: end; muss normalisiert werden auf 0: .. 4: ohne "n" zu ändern | |||
* case statement ohne "ranges", also KEIN 0..18 | * case statement ohne "ranges", also KEIN 0..18 |
Version vom 18. Oktober 2017, 09:23 Uhr
Freepascal oder fpc ist ein freier Pascal / Delphi(tm) Compiler. Der Entwicklungsstand kann mit Turbo Pascal(tm) 7.0 erweitert um aktuelle Delphi(tm) Sprachelemente verglichen werden. OrgaMon verwendet Freepascal für die Linux-Server-Seite des OrgaMon in den Projekten keepcon, domadd, cOrgaMon. cOrgaMon wird unter Windows mit der Entwicklungsumgebung Lazarus entwickelt.
Installation
- Für OpenSuse sollten ausschliesslich für diese Plattform compilierte Pakete verwendet werden. Das Standard 64-Bit Paket von Sourceforge wird nicht laufen!
# # Option 1: aus "Factory" # zypper ar --refresh http://download.opensuse.org/repositories/devel:/languages:/pascal/openSUSE_Factory/devel:languages:pascal.repo # # Option 2: aus "42.1" # zypper ar --refresh http://download.opensuse.org/repositories/devel:languages:pascal/openSUSE_Leap_42.1/devel:languages:pascal.repo # # ein erstmaliger Download des Repository-Index, dem "Key" kann man mit # Taste <A> dauerhaft vertrauen # zypper refresh
# # die eigentliche Installation # zypper install lazarus
Spracherweiterungen
- hier fasse ich einige Spracherweiterungen auf, die mir so einfallen
- Intel Parallel Building Blocks (PBB)
- OpenMP
- Ev. kommt mir hier das kommende LLVM Target von FreePascal zugute
"param" anstelle von "var"
var
MomentTimeout : ANFiXDate; Parameter;
c,i,r : integer; Parameter;
begin
// all zu alte Einträge löschen
MomentTimeout := DatePlus(DateGet, -10);
i := 0;
c := colOf('MOMENT');
for r := RowCount downto 1 do
if (StrToIntDef(readCell(r, c), 0) < MomentTimeout) then
begin
del(r);
inc(i);
end;
if (i > 0) then
Log('INFO: ' + 'gebe ' + inttostr(i) +
' Dateieinträge frei, da sie älter als 10 Tage sind');
end;
"param" Variable sind wie "var" Variable, die aber erst gesetzt werden, wenn ein (erster) lesender Zugriff erfolgt. Das "Setzen" des VAriablen-Wertes erfolgt gar nicht, an dieser Stelle wird kein Code ausgeführt, erst beim ersten Vergleich wird "MomentTimeout" gesetzt. Danach wird MomentTimeout wie eine normale Variable verwendet. Dadurch lässt sich der Code übersichtlicher gestalten. Man kann die "gathering" Phase schön beisammenhalten - auch wenn die die Kosten hoch sind. Es wird jedoch keine Zeit verbraten, und eine Menge komplexe if-Bedingungen gespart.
nebenläufige Zuweisung
var a,b : integer; Concurrent; begin a := sql('count SOULS from EARTH'); b := sql('count STARS from UNIVERSE'); if (a>=b) then beep; end;
Die Zuweisung nach a erfolgt in einem eigenen Thread. DIe Codeausführung wird sofort mit der nächsten Zeile fortgesetzt. Auch für die Zuweisung zu b wird ein Thread gestartet. Erst bei einem lesenden Zugriff auf a oder b wird auf das Ergebnis (= Beendigung des Threads) gewartet, ein erneuter schreibender ZUgriff auf a oder b würde den Thread ohne Warten auf das Ergebnis abbrechen.
case statement
- fpc\compiler\x86_64\nx64set.pas Line 63 ff
- Optimierung nur bei -Os, (=size), ich halte aber auch "speed" für ein Argument
Es ist eine Optimierung beim Freepascal Case Statement möglich, wenn z.B. anhand eines enum-Types unterschieden werden soll:
- die Optimierung für bei einer Hohen Granularität sind keiner erhöhten Code Grösse
- Beispiel, ein Range verschlechtert die Granularität 99..110 würde 12 JMP Table Einträge erzeugen!
- bei wesentlichen Lücken im case Statement würden viele "NOP"-Einträge entstehen
- case n of 0: 20: else end; es würden für 1..19 "Lücken" entstehen, die alle nach "else" springen
- Linear-Verschiebung, Normalisierung: case n -2: -1: 0: 1: 2: end; muss normalisiert werden auf 0: .. 4: ohne "n" zu ändern
- case statement ohne "ranges", also KEIN 0..18
- case statement ohne nennenswerte Lücken
JMP [Table+AX*8]
.GLOBAL calculate
calculate:
pushl %ebp
movl %esp,%ebp
movl 12(%ebp),%eax
movl 8(%ebp),%ecx
cmpl $2,%ecx
ja done
jmp *operations(,%ecx,4)
operation1:
imull %eax,%eax
jmp done
operation2:
negl %eax
jmp done
operation3:
addl $0x80,%eax
done:
leave
ret
operations:
.long operation1, operation2, operation3
my way would be (assumed 64-bit mode yet): ;entry in rax and all entries contain a valid address ;a limit check here may not hurt much. jmp [table+rax*8] ;if in the data-seg or jmp cs:[table+rax*8] ;if the table is part of the code section ;also possible if your compiler is able to: jmp [rip+table_offset+rax*8] ;RIP access uses CS by default __ wolfgang
The code I posted here first was a test-case-stand-alone example that I constructed so I could learn how to write jump tables. In the end though I am looking to include an assembly function into a library which is built in a static and a dynamic version using libtool and autoconf/automake. As I mentioned on linux-assembly, the linker was complaining about my jump table telling me that it can't relocate some symbols. I used a C program with a large switch statement and gcc with -fPIC to see how to deal with PIC and am using the version below now. Just as gcc does, I placed the jump table in .section .rodata, but I am not sure if that's equivalent to placing it in the .data section or not. .text .global jump_table .type jump_table, @function jump_table: # Push stack pointer so we can make room for local storage. push %rax mov $0x02, %rax # Move index into rax; 2 is supposed to end up at label_02. lea 0(,%rax, 4), %rdx lea table(%rip), %rax mov (%rdx, %rax), %edx movslq %edx, %rdx lea table(%rip), %rax lea (%rdx, %rax), %rax jmp *%rax .section .rodata .align 4 table: .long label_00-table .long label_01-table .long label_02-table .long label_03-table .text label_00: jmp done label_01: jmp done label_02: jmp done label_03: jmp done done: pop %rax ret .size jump_table, .-jump_table
- fpc\tests\webtbs\tw10641.pp (Jumptable)
- fpc\tests\webtbs\tw3577.pp (Jumptable)
- fpc\tests\webtbs\tw11638.pp (Code-Länge des JMP)
Umsetzungsprobleme
- ich habe keine Möglichkeit im Assembler mir zu wünschen dass immer ein far-Jump mit 5 Bytes erstellt wird, es wird optimiert und zwar ensteht bein kurzen Jumps ein 2 Byte grosser Befehl
- will ich den Befehl selbst codieren, dann ensteht 2 neue Probleme:
- DB $e9,$72,$00,$00,$00 also ich bekomme das $7 nicht hin (dieses Bit ist vorgegeben)
- DB $e9
- DB $70|(@there-@here) // 1. Problem: binäres oder? 2.Problem: Minus Operation