Forum > General

Moving from Virtual Pascal to Free Pascal

(1/7) > >>

prino:
I've been using VP since about the time it became free, and I'm very happy with it, especially because it has several features that are, I've tried FPC of more than one occasion, essential for me. The first and foremost of these is that VP carried over a feature that originated in, probably TP4: if you define a set of two (or more) const's in a single declaration, like

const
  lift_ptr : liftptr  = nil;
  lift_top : liftptr  = nil;
  lift_end : liftptr  = nil;

All, in this case, three will end up in the executable, even though one of them may never ever be referenced directly, if the address of "lift_ptr" is passed, the called routine knows that the other two immediately follow in storage. This is sadly still not the case in FPC, and as most of my programs, which rely heavily on linked-list processing, extensively use this feature, converting them is far from trivial, very far. I think I've once flagged it, but tries over the past years have shown that it's still not implemented.

The other feature that I use all the time, is the fact that VP allows direct access to the RTL, and as a consequence, most of my original Pascal code has, over the past years, been converted into highly optimised inline assembler, as the code generated by VP is just about, how do I say this politely, brown-stuffish, as the code generated by the last Borland compiler I used extensively, TP6. Given that my tries using FPC show all kinds of mangled names, this seems impossible in FPC. Is it? Or is it not? Needlessly to say, I do keep a "pure Pascal" version of the code around

Quite amazingly, given that much of it dates back to 1994, it also lent itself very well for conversion to AVX, and as a result, I'm using that extensively and in VP that means using lots of "db ...", and here, I think, FPC would have an advantage, allowing me this in real inline assembler, if it supports AVX. Does it? And does its debugger?

marcov:
The multi VAR bit it is IMHO not a feature, but simply a lack of optimization in the ancient compilers. I sincerely doubt these compilers documented this anywhere.

I don't fully understand the direct access to the RTL bit, but the internal assembler should deal with name mangling just fine.

Fibonacci:

--- Quote from: prino on February 08, 2024, 01:50:33 pm ---const
  lift_ptr : liftptr  = nil;
  lift_top : liftptr  = nil;
  lift_end : liftptr  = nil;

All, in this case, three will end up in the executable, even though one of them may never ever be referenced directly, if the address of "lift_ptr" is passed, the called routine knows that the other two immediately follow in storage. This is sadly still not the case in FPC, and as most of my programs, which rely heavily on linked-list processing, extensively use this feature, converting them is far from trivial, very far. I think I've once flagged it, but tries over the past years have shown that it's still not implemented.

--- End quote ---

What is the purpose of this? I guess you can put it in a record, then you can be sure they are next to each other.


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---var  lift: packed record    lift_ptr: pointer;    lift_top: pointer;    lift_end: pointer;  end; procedure test(arg: pointer);begin  writeln('first = ', PPtrUInt(arg)[0]);  writeln('next  = ', PPtrUInt(arg)[1]);  writeln('next  = ', PPtrUInt(arg)[2]);   end; begin  // fill to test  lift.lift_ptr := pointer(123);  lift.lift_top := pointer(456);  lift.lift_end := pointer(789);   test(@lift.lift_ptr);   readln;end.

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---first = 123next  = 456next  = 789

dseligo:

--- Quote from: Fibonacci on February 08, 2024, 02:08:47 pm ---What is the purpose of this? I guess you can put it in a record, then you can be sure they are next to each other.

--- End quote ---

Or in array:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---type TLift = (lift_ptr, lift_top, lift_end); const  lift: array [TLift] of liftptr = (nil, nil, nil);

Thaddy:
If you can provide the Virtual pascal code, I can probably show you what the alternatives are. Note VP has constructions that are implemented completely different from FreePascal, but usually there is an alternative.
I only need snippets with full declarations and types.
The loop can not possibly cause an 80% load because it is well written

Navigation

[0] Message Index

[#] Next page

Go to full version