Forum > General

Question on portable code

<< < (2/3) > >>

Blaazen:

--- Quote ---With "safe" you mean it's a common Pascal RTL function?
--- End quote ---

Yes. It is FPC equivalent to
--- Code: --- i++
--- End code ---
in C/C++. IMO writing your own fucntion with IFDEF is overengeneered solution. If there's any target platform which doesn't have instruction for inc() then the same is very probably already done inside compiler.

Leledumbo:

--- Quote from: MathMan on August 11, 2015, 08:35:06 am ---Using Inc instead will produce significantly faster executables on my Version of FPC
...
* if Inc/Dec is not portable can I expect better optimization in the upcomming FPC 3.x.x Versions (so that i can stay with the above)?

--- End quote ---
Since early FPC days, both should generate the same opcode if you use optimization (no idea about the minimum level, 2 I believe).

--- Quote from: MathMan on August 11, 2015, 08:35:06 am ---* is Inc/Dec a common Pascal language extension (or should I stay with the above for portablilty)?

--- End quote ---
To date, all active Pascal compilers are usually Turbo Pascal compatible. Inc/Dec should be available in all of them.

Thaddy:
Even w/o optimization the code for inc(x,a)  and x := x + a is identical for intel x86 processors.....

It used to be the case that on x86 family processors it was directly converted to the asm inc instruction.
But processors have evolved and this is no longer always the case.

You should never optimize with a specific processor in mind.
If you really want your code to compile with as many pascal dialects as possible, simply optimize your algorithms.

But your question was not very clear: do you mean compilers different from Freepascal or do you mean Freepascal compilers for different platforms and cpu's?

If the latter is the case, FPC will optimize as best as it can given the available instruction set.

AIR even UCSD Pascal supported inc (I taught UCSD Pascal on Apple ]['s at university to my fellow students in the early 80's) but it could have been a function instead of an intrinsic.

Leledumbo:

--- Quote from: Thaddy on August 11, 2015, 11:00:30 am ---Even w/o optimization the code for inc(x,a)  and x := x + a is identical for intel x86 processors.....

--- End quote ---
Not really, the following program:

--- Code: ---program test;

procedure p;
var
  x: longword;
begin
  x := x + 1;
end;

procedure q;
var
  x: longword;
begin
  Inc(x);
end;

begin
  p;q
end.

--- End code ---
generates this asm when compiled without optimization (relevant parts only):

--- Code: ---# P
# Var x located at ebp-4, size=OS_32
# [7] x := x + 1;
movl -4(%ebp),%eax
leal 1(%eax),%eax
movl %eax,-4(%ebp)
# [8] end;

# Q
# Var x located at ebp-4, size=OS_32
# [14] Inc(x);
addl $1,-4(%ebp)
# [15] end;

--- End code ---
Recompile with -O1:

--- Code: ---// P
# Var x located at ebp-4, size=OS_32
# [7] x := x + 1;
movl -4(%ebp),%eax
addl $1,%eax

// Q
# Var x located at ebp-4, size=OS_32
# [14] Inc(x);
addl $1,-4(%ebp)
# [15] end;

--- End code ---
and -O2:

--- Code: ---// P
# [7] x := x + 1;
addl $1,%eax
# Var x located in register eax
# [8] end;

// Q
# Var x located in register eax
# [13] begin
# [14] Inc(x);
addl $1,%eax
# [15] end;

--- End code ---
As can be seen, they're only equal in -O2 optimization. Note that I'm cross compiling from x86_64 to i386 and x must be of 32-bit integer type, in x86_64 even when the integer type matches processor native pointer size (64-bit) they're never equal.

Thaddy:
My bad since O2 is debuggable and my default.. The rest of my comments are valid though.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version