Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Perhaps you may first try get it running with the large memory model, 
and if this runs, try to optimize it for a smaller memory model? The 
following least compiles for me, with A BUNCH of warnings, and the 
binary is 68k in size, comparing to 11k in the bin folder (did you UPX 
compress it or is it the actual size?)


ppcross8086 -Mtp -WmLarge KEYB.PAS

Warnings like:

Warning: Use of +offset(%ebp) is not compatible with regcall convention

look rather fishy, considering we are dealing with 16-bit code.

Your unaltered source leads to the following warnings, mainly dealing 
with the inline assemly.


Free Pascal Compiler version 3.2.2 [2021/05/19] for i8086

Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: MS-DOS 16-bit real mode
Compiling KEYB.PAS
KEYB.PAS(23,2) Warning: The switch "$E" is not supported by the 
currently selected target

KEYB.PAS(23,2) Warning: Unsupported switch "$L"
KEYB.PAS(23,2) Warning: Unsupported switch "$N"
KEYB.PAS(23,2) Warning: Unsupported switch "$Y"
KEYB.PAS(281,41) Warning: Size suffix and destination or source size do 
not match
KEYB.PAS(298,41) Warning: Size suffix and destination or source size do 
not match
KEYB.PAS(464,21) Warning: Use of +offset(%ebp) is not compatible with 
regcall convention
KEYB.PAS(471,24) Warning: Use of +offset(%ebp) is not compatible with 
regcall convention

KEYB.PAS(474,4) Warning: Label not defined "changecpexit"
KEYB.PAS(549,40) Warning: Size suffix and destination or source size do 
not match

KEYB.PAS(620,4) Warning: Label not defined "NotReplace"
KEYB.PAS(660,25) Warning: Use of +offset(%ebp) is not compatible with 
regcall convention
KEYB.PAS(962,40) Warning: Size suffix and destination or source size do 
not match
KEYB.PAS(1015,24) Warning: Use of +offset(%ebp) is not compatible with 
regcall convention
KEYB.PAS(1016,24) Warning: Use of +offset(%ebp) is not compatible with 
regcall convention

KEYB.PAS(1020,4) Warning: Label not defined "ChainScancodeEnd"
KEYB.PAS(1245,41) Warning: Size suffix and destination or source size do 
not match
KEYB.PAS(1344,40) Warning: Size suffix and destination or source size do 
not match

KEYB.PAS(1510,4) Warning: Label not defined "no100"
KEYB.PAS(1510,4) Warning: Label not defined "no101"
KEYB.PAS(1510,4) Warning: Label not defined "no161"
KEYB.PAS(1676,4) Warning: Label not defined "WaitReady1"
KEYB.PAS(1908,4) Warning: Label not defined "jmp1"
KEYB.PAS(1908,4) Warning: Label not defined "jmp2"
KEYB.PAS(1908,4) Warning: Label not defined "ende"
KEYB.PAS(1908,4) Warning: Label not defined "BufferFull1"
KEYB.PAS(1908,4) Warning: Label not defined "ende2"
KEYB.PAS(2412,18) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(2630,14) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(2631,28) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(2653,17) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(2654,17) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(2655,17) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(2656,17) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(2987,12) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(3316,23) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(3328,23) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(3344,21) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(3349,27) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(3358,9) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined
KEYB.PAS(3358,22) Note: Call to subroutine "function 
Ptr(sel:Word;off:Word):^untyped; far;" marked as inline is not inlined

KEYB.PAS(2923,6) Note: Local variable "pb" not used
Linking KEYB.exe
3466 lines compiled, 0.1 sec, 60578 bytes code, 4080 bytes data
27 warning(s) issued

15 note(s) issued


Greetings, Bernd

On 01.01.2024 22:01, Aitor Santamaría via Freedos-devel wrote:

Hello there!

Sorry for being late on the topic.

The following link directs to the forum item that I opened when trying 
to re-compile FD-KEYB under FPC.
Basically, KEYB needs to use different procedures to store a key in 
the buffer, depending on the parameters and system configuration. The 
problem occurs when I need to select the adequate key storing 
procedure 

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Aitor Santamaría via Freedos-devel]

Hello there!

Sorry for being late on the topic.

The following link directs to the forum item that I opened when trying to
re-compile FD-KEYB under FPC.
Basically, KEYB needs to use different procedures to store a key in the
buffer, depending on the parameters and system configuration. The problem
occurs when I need to select the adequate key storing procedure to a
variable that will be called from the assembly bit. It also occurs in some
other parts.

In order to make the program small, I am compiling it under the compact
mode. I tried it and had this error last October, and as no one posted a
reply, I haven't tried it again, but can do it (or maybe someone here can
guess where the problem is).

I get a problem using both the standar or the TP mode, and doing @Procedure
or without the @.
You can read the full details here, maybe someone has a hint:

Far pointer versus Pointer in 16-bit DOS (freepascal.org)


Thanks in advance,
Aitor











On Mon, 13 Nov 2023 at 00:40, Rugxulo via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Hi,
>
> On Sun, Nov 12, 2023 at 5:46 AM Bernd Böckmann via Freedos-devel
>  wrote:
> >
> > On 12.11.2023 02:44, Rugxulo via Freedos-devel wrote:
> >
> > But I still have not found an elegant solution yet to do a widening
> conversion of an untyped pointer from near to far.
> > Should be rarely needed though. For a typed pointer FarAddr(thing^) does
> the trick.
>
> You can get the current code segment or data segment with the CSeg and
> DSeg functions.
>
> * https://www.freepascal.org/docs-html/rtl/system/seg.html
>
> Also see the "absolute" keyword:
>
> * https://wiki.freepascal.org/Absolute
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Rugxulo via Freedos-devel]

Hi,

On Sun, Nov 12, 2023 at 5:46 AM Bernd Böckmann via Freedos-devel
 wrote:
>
> On 12.11.2023 02:44, Rugxulo via Freedos-devel wrote:
>
> But I still have not found an elegant solution yet to do a widening 
> conversion of an untyped pointer from near to far.
> Should be rarely needed though. For a typed pointer FarAddr(thing^) does the 
> trick.

You can get the current code segment or data segment with the CSeg and
DSeg functions.

* https://www.freepascal.org/docs-html/rtl/system/seg.html

Also see the "absolute" keyword:

* https://wiki.freepascal.org/Absolute


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

On 12.11.2023 02:44, Rugxulo via Freedos-devel wrote:

FarAddr internal function


Thanks, that brings me further :-)

I also changed my coding style from a more C oriented style to a more 
Pascal like. Unlike in C, one does not have to pass around (explicit) 
pointers that often. For example instead of doing


procedure F(buffer : FarPointer);

I now do:

procedure F(var buffer);
begin
...
... FarAddr(buffer) ...
...

But I still have not found an elegant solution yet to do a widening 
conversion of an untyped pointer from near to far. Should be rarely 
needed though. For a typed pointer FarAddr(thing^) does the trick.


Bernd

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Rugxulo via Freedos-devel]

Hi again,

On Fri, Nov 10, 2023 at 7:56 AM Bernd Böckmann via Freedos-devel
 wrote:
>
> >
> > I believe int64 was originally from Delphi. (Isn't there also "long
> > long" support in OpenWatcom via "-za99“?)
>
> Yes, Watcom C supports 64-bit integer arithmetic, in contrast to Turbo C 3.1, 
> which to my knowledge does not,
> but silently interprets „long long x“ as „long x“, yielding a 32-bit integer 
> type.

Would something like this (assembly, 8086 and 386) help?

"Fast 64-bit Signed Integer Arithmetic Routines (Roger Moser)"
* http://cd.textfiles.com/ems/emspro1/ASMUTIL/QMATH0.ZIP

Or how about this (32-bit assembly)?

"Efficient [Unsigned] 64-Bit Integer Arithmetic in 32-Bit Mode (AMD)"
* 
http://web.archive.org/web/2020110100*/https://sites.google.com/site/rugxulo/32math64.txt?attredirects=0


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Rugxulo via Freedos-devel]

Hi,

On Thu, Nov 9, 2023 at 4:39 PM Bernd Böckmann via Freedos-devel
 wrote:
>
>  > Could you please post the exact message you got from the compiler?
>
> For something like this "FarPointer(@Buffer)" I get the following error
> message:
>
> "Error: Illegal type conversion: "Pointer" to "FarPointer""
>
> My opinion is that this should be supported by the compiler, because it
> is well defined for the small memory model I am working in.

I had thought @ was just an alias for the built-in Addr() function.
(In classic / ISO Pascal, you can't get the address of anything, and
'@' is a character substitute for '^'.)

A quick search shows this:

* https://wiki.freepascal.org/FPC_New_Features_3.2.0

FarAddr internal function

Overview: There's a new i8086-specific internal function, similar to
Addr(), called FarAddr(), which always returns a far pointer to the
address of its argument.
Notes: The built-in Addr() function and the @ operator return a
pointer type (near or far), that depends on the memory model. When
interfacing with DOS, BIOS and other 16-bit APIs, it is sometimes
useful to be able to obtain a far pointer to a pascal variable or
procedure/function, regardless of the selected memory model.
Previously, you would have to use ifdefs, or do something like
Ptr(Seg(x), Ofs(x)). Now, this can be replaced with the much nicer
FarAddr(x).
svn: r37629


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

> 
> I believe int64 was originally from Delphi. (Isn't there also "long
> long" support in OpenWatcom via "-za99“?)

Hello Rugxulo,

Yes, Watcom C supports 64-bit integer arithmetic, in contrast to Turbo C 3.1, 
which to my knowledge does not, but silently interprets „long long x“ as „long 
x“, yielding a 32-bit integer type.



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Hello Hippo,

thanks for the hint. I have a copy of Borland Pascal 7 inherited from my 
father. In fact I think I have learned programming with it when I was a kid, or 
with a previous version. Fascinating piece of software. But I prefer to build 
open tools with open tools :-)

Greetings, Bernd


> Am 10.11.2023 um 00:37 schrieb Danilo Pecher via Freedos-devel 
> :
> 
> As far as I know the earlier Turbo-Pascal compilers (I think 5.5 and
> earlier) have been freeware'd years ago. They can natively compile
> 16bit code on Freedos and might be worth a try. You can find even
> ancient versions of TP, like 3.0 on winworldpc, and I actually quite
> like to go down memory lane once in a while, although I have ported
> most of my projects to Watcom C by now.
> 
> cheers, Hippo
> 
> On Thu, 9 Nov 2023 at 23:44, Bernd Böckmann via Freedos-devel
>  wrote:
>> 
>> Btw, when compiling in large memory model via
>> 
>> fpc -Wmlarge
>> 
>> the pointer errors when compiling keyb are gone. There are some 20
>> remaining compile errors. Perhaps these can be solved.
>> 
>> Bernd
>> 
>> On 09.11.2023 23:38, Bernd Böckmann via Freedos-devel wrote:
>>> Hello Aitor,
>>> 
 Could you please post the exact message you got from the compiler?
>>> 
>>> For something like this "FarPointer(@Buffer)" I get the following
>>> error message:
>>> 
>>> "Error: Illegal type conversion: "Pointer" to "FarPointer""
>>> 
>>> My opinion is that this should be supported by the compiler, because
>>> it is well defined for the small memory model I am working in.
>>> 
>>> I looked into the keyb source code and tried to compile it with
>>> FreePascal. One problematic line is for example:
>>> 
>>> PWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
>>> 
>>> Here, Ptr emits a far pointer, and PWord would cast this to a near
>>> pointer. FreePascal complains about it.
>>> 
>>> BUT the following at least gets accepted by the compiler:
>>> 
>>>type PFarWord = ^Word; far;
>>> 
>>> PFarWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
>>> 
>>> This converts it to a typed FAR pointer, which than can be de-referenced.
>>> 
>>> What is more concerning are error messages like:
>>> 
>>> "Warning: Use of +offset(%ebp) is not compatible with regcall
>>> convention", since there is not a trace of 32 bit instructions in the
>>> code.
>>> 
>>> Bernd
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Freedos-devel mailing list
>>> Freedos-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>> 
>> 
>> ___
>> Freedos-devel mailing list
>> Freedos-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Danilo Pecher via Freedos-devel]

As far as I know the earlier Turbo-Pascal compilers (I think 5.5 and
earlier) have been freeware'd years ago. They can natively compile
16bit code on Freedos and might be worth a try. You can find even
ancient versions of TP, like 3.0 on winworldpc, and I actually quite
like to go down memory lane once in a while, although I have ported
most of my projects to Watcom C by now.

cheers, Hippo

On Thu, 9 Nov 2023 at 23:44, Bernd Böckmann via Freedos-devel
 wrote:
>
> Btw, when compiling in large memory model via
>
> fpc -Wmlarge
>
> the pointer errors when compiling keyb are gone. There are some 20
> remaining compile errors. Perhaps these can be solved.
>
> Bernd
>
> On 09.11.2023 23:38, Bernd Böckmann via Freedos-devel wrote:
> > Hello Aitor,
> >
> > > Could you please post the exact message you got from the compiler?
> >
> > For something like this "FarPointer(@Buffer)" I get the following
> > error message:
> >
> > "Error: Illegal type conversion: "Pointer" to "FarPointer""
> >
> > My opinion is that this should be supported by the compiler, because
> > it is well defined for the small memory model I am working in.
> >
> > I looked into the keyb source code and tried to compile it with
> > FreePascal. One problematic line is for example:
> >
> >  PWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
> >
> > Here, Ptr emits a far pointer, and PWord would cast this to a near
> > pointer. FreePascal complains about it.
> >
> > BUT the following at least gets accepted by the compiler:
> >
> > type PFarWord = ^Word; far;
> >
> >  PFarWord ( ptr(m-1,1) )^ := m;{ make it self-parented }
> >
> > This converts it to a typed FAR pointer, which than can be de-referenced.
> >
> > What is more concerning are error messages like:
> >
> > "Warning: Use of +offset(%ebp) is not compatible with regcall
> > convention", since there is not a trace of 32 bit instructions in the
> > code.
> >
> > Bernd
> >
> >
> >
> >
> > ___
> > Freedos-devel mailing list
> > Freedos-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Btw, when compiling in large memory model via

fpc -Wmlarge

the pointer errors when compiling keyb are gone. There are some 20 
remaining compile errors. Perhaps these can be solved.


Bernd

On 09.11.2023 23:38, Bernd Böckmann via Freedos-devel wrote:

Hello Aitor,

> Could you please post the exact message you got from the compiler?

For something like this "FarPointer(@Buffer)" I get the following 
error message:


"Error: Illegal type conversion: "Pointer" to "FarPointer""

My opinion is that this should be supported by the compiler, because 
it is well defined for the small memory model I am working in.


I looked into the keyb source code and tried to compile it with 
FreePascal. One problematic line is for example:


 PWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

Here, Ptr emits a far pointer, and PWord would cast this to a near 
pointer. FreePascal complains about it.


BUT the following at least gets accepted by the compiler:

    type PFarWord = ^Word; far;

 PFarWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

This converts it to a typed FAR pointer, which than can be de-referenced.

What is more concerning are error messages like:

"Warning: Use of +offset(%ebp) is not compatible with regcall 
convention", since there is not a trace of 32 bit instructions in the 
code.


Bernd




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Hello Aitor,

> Could you please post the exact message you got from the compiler?

For something like this "FarPointer(@Buffer)" I get the following error 
message:


"Error: Illegal type conversion: "Pointer" to "FarPointer""

My opinion is that this should be supported by the compiler, because it 
is well defined for the small memory model I am working in.


I looked into the keyb source code and tried to compile it with 
FreePascal. One problematic line is for example:


 PWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

Here, Ptr emits a far pointer, and PWord would cast this to a near 
pointer. FreePascal complains about it.


BUT the following at least gets accepted by the compiler:

    type PFarWord = ^Word; far;

 PFarWord ( ptr(m-1,1) )^ := m;    { make it self-parented }

This converts it to a typed FAR pointer, which than can be de-referenced.

What is more concerning are error messages like:

"Warning: Use of +offset(%ebp) is not compatible with regcall 
convention", since there is not a trace of 32 bit instructions in the code.


Bernd




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Aitor Santamaría via Freedos-devel]

Hello,

Could you please post the exact message you got from the compiler?

I got mysefl problems with such convertions trying to compile FD-KEYB with
FPC, but although I posted for help in the forums, I didn't get anything
really useful and finally gave up.
But I am curious if you get the same error.

There's a compatibility mode that makes you switch between using @ or not
before the procedure address, but in either case I got different compile
time errors that made it unable for me to continue.

Thanks,
Aitor




On Thu, 9 Nov 2023 at 00:52, Rugxulo via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Hi,
>
> On Wed, Nov 8, 2023 at 2:21 PM Bernd Böckmann via Freedos-devel
>  wrote:
> >
> > the tests I did showed that FreePascal is perfectly capable of producing
> > reasonably small binaries fitting the small memory model, if you do not
> > require the full language feature set (stay away from ObjFpc / Delphi
> > modes). SysUtils and exception handling pulls in a significant amount of
> > code, so you either stick with plain FPC or TP modes or have to live
> > with large memory model.
>
> FPC mode is the default and (I believe) allows function overloading
> and structured return values (with slightly different function pointer
> syntax).
>
> > I am not that interested in Turbo Pascal compatibility, so I can not say
> > anything about it. For me, FreePascal provides some benefits over Turbo
> > Pascal, taking my specific use case into account: e.g. 64-bit arithmetic
> > in 8086 real mode.
>
> I believe int64 was originally from Delphi. (Isn't there also "long
> long" support in OpenWatcom via "-za99"?)
>
> > To the specific problem: I have to provide a FAR pointer to the BIOS as
> > a member of an INT13 device access packet. That pointer shall point to a
> > 512 byte array, for which I get a near pointer via the @ address
> > operator. This near pointer has to be converted to a far pointer.
> > Because this operation is clearly defined for the small memory model, I
> > asked if someone knows that a built-in solution exists. But perhaps this
> > question is better addressed to the FreePascal community. In the
> > meantime, I will use the function from my last mail.
>
> Dunno, directly ask FPC guys MarcoV or NickySn. Sometimes they
> frequent the BTTR Forum too.
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Rugxulo via Freedos-devel]

Hi,

On Wed, Nov 8, 2023 at 2:21 PM Bernd Böckmann via Freedos-devel
 wrote:
>
> the tests I did showed that FreePascal is perfectly capable of producing
> reasonably small binaries fitting the small memory model, if you do not
> require the full language feature set (stay away from ObjFpc / Delphi
> modes). SysUtils and exception handling pulls in a significant amount of
> code, so you either stick with plain FPC or TP modes or have to live
> with large memory model.

FPC mode is the default and (I believe) allows function overloading
and structured return values (with slightly different function pointer
syntax).

> I am not that interested in Turbo Pascal compatibility, so I can not say
> anything about it. For me, FreePascal provides some benefits over Turbo
> Pascal, taking my specific use case into account: e.g. 64-bit arithmetic
> in 8086 real mode.

I believe int64 was originally from Delphi. (Isn't there also "long
long" support in OpenWatcom via "-za99"?)

> To the specific problem: I have to provide a FAR pointer to the BIOS as
> a member of an INT13 device access packet. That pointer shall point to a
> 512 byte array, for which I get a near pointer via the @ address
> operator. This near pointer has to be converted to a far pointer.
> Because this operation is clearly defined for the small memory model, I
> asked if someone knows that a built-in solution exists. But perhaps this
> question is better addressed to the FreePascal community. In the
> meantime, I will use the function from my last mail.

Dunno, directly ask FPC guys MarcoV or NickySn. Sometimes they
frequent the BTTR Forum too.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Rugxulo via Freedos-devel]

Hi,

On Wed, Nov 8, 2023 at 1:42 PM Bernd Böckmann via Freedos-devel
 wrote:
>
> has anyone recently played around with the FreePascal 8086 cross
> compiler to generate DOS executables? I try to convert a near pointer to
> a far pointer while working under the small memory model, but that is
> not as trivial as it should be, because I have not found a language /
> library feature for it.
>
> I came up with the following solution, but I am wondering if I have
> overlooked something built-in?

Try reading this:

* https://wiki.freepascal.org/DOS#New_pointer_types

Yes, I sometimes play around with FPC i8086-msdos, but I've never
really messed with mixed memory model programming.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Hi Ralf,

the tests I did showed that FreePascal is perfectly capable of producing 
reasonably small binaries fitting the small memory model, if you do not 
require the full language feature set (stay away from ObjFpc / Delphi 
modes). SysUtils and exception handling pulls in a significant amount of 
code, so you either stick with plain FPC or TP modes or have to live 
with large memory model.


I am not that interested in Turbo Pascal compatibility, so I can not say 
anything about it. For me, FreePascal provides some benefits over Turbo 
Pascal, taking my specific use case into account: e.g. 64-bit arithmetic 
in 8086 real mode.


To the specific problem: I have to provide a FAR pointer to the BIOS as 
a member of an INT13 device access packet. That pointer shall point to a 
512 byte array, for which I get a near pointer via the @ address 
operator. This near pointer has to be converted to a far pointer. 
Because this operation is clearly defined for the small memory model, I 
asked if someone knows that a built-in solution exists. But perhaps this 
question is better addressed to the FreePascal community. In the 
meantime, I will use the function from my last mail.


Greetings, Bernd


On 08.11.2023 20:57, Ralf Quint via Freedos-devel wrote:

On 11/8/2023 11:40 AM, Bernd Böckmann via Freedos-devel wrote:

Hi all,

has anyone recently played around with the FreePascal 8086 cross 
compiler to generate DOS executables? I try to convert a near pointer 
to a far pointer while working under the small memory model, but that 
is not as trivial as it should be, because I have not found a 
language / library feature for it. For example, a cast operation does 
not work. But the semantics should be well defined (for the small 
memory model): set the segment part of the far pointer to DS.


I came up with the following solution, but I am wondering if I have 
overlooked something built-in?


function ToFarPointer(nearP: NearPointer) : FarPointer;
  var p: packed record ofs: NearPointer; segm: Word; end;
begin
  p.ofs := nearP;
  asm
    mov ax, seg @data
    mov [p.segm], ax
  end;
  ToFarPointer := FarPointer(p);
end;

(the above of course only works with the small / tiny / compact 
memory models)


Greetings, Bernd 
How are you even working in the "small" memory model in FreePascal? 
One of the problems that I noticed when trying to use the 8086 version 
of FreePascal long time ago was that while someone went through the 
length of generating 8086 code, there was little compatibility with 
Turbo/Borland Pascal and actually DOS.
"small" memory model means that you have a fixed code AND data 
segment, and all pointers are just offsets within those segments. Not 
having the definitions of NearPointer and FarPointer from the above 
snippet, one thing to consider is that when changing either CS or DS 
segments in a small memory model program, you need to make sure that 
you ALWAYS save and restore those segments when changing them 
temporarily...


I am pretty sure that the actual compatibility with the DOS 
environment has not significantly improved since I tried. And as in 
Pascal, by default you should not be messing with any pointers 
directly, any such feature to do so would be a very specific 
implementation/library issue...



Ralf





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreePascal near to far pointer conversion

[Ralf Quint via Freedos-devel]

On 11/8/2023 11:40 AM, Bernd Böckmann via Freedos-devel wrote:

Hi all,

has anyone recently played around with the FreePascal 8086 cross 
compiler to generate DOS executables? I try to convert a near pointer 
to a far pointer while working under the small memory model, but that 
is not as trivial as it should be, because I have not found a language 
/ library feature for it. For example, a cast operation does not work. 
But the semantics should be well defined (for the small memory model): 
set the segment part of the far pointer to DS.


I came up with the following solution, but I am wondering if I have 
overlooked something built-in?


function ToFarPointer(nearP: NearPointer) : FarPointer;
  var p: packed record ofs: NearPointer; segm: Word; end;
begin
  p.ofs := nearP;
  asm
    mov ax, seg @data
    mov [p.segm], ax
  end;
  ToFarPointer := FarPointer(p);
end;

(the above of course only works with the small / tiny / compact memory 
models)


Greetings, Bernd 
How are you even working in the "small" memory model in FreePascal? One 
of the problems that I noticed when trying to use the 8086 version of 
FreePascal long time ago was that while someone went through the length 
of generating 8086 code, there was little compatibility with 
Turbo/Borland Pascal and actually DOS.
"small" memory model means that you have a fixed code AND data segment, 
and all pointers are just offsets within those segments. Not having the 
definitions of NearPointer and FarPointer from the above snippet, one 
thing to consider is that when changing either CS or DS segments in a 
small memory model program, you need to make sure that you ALWAYS save 
and restore those segments when changing them temporarily...


I am pretty sure that the actual compatibility with the DOS environment 
has not significantly improved since I tried. And as in Pascal, by 
default you should not be messing with any pointers directly, any such 
feature to do so would be a very specific implementation/library issue...



Ralf





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] FreePascal near to far pointer conversion

[Bernd Böckmann via Freedos-devel]

Hi all,

has anyone recently played around with the FreePascal 8086 cross 
compiler to generate DOS executables? I try to convert a near pointer to 
a far pointer while working under the small memory model, but that is 
not as trivial as it should be, because I have not found a language / 
library feature for it. For example, a cast operation does not work. But 
the semantics should be well defined (for the small memory model): set 
the segment part of the far pointer to DS.


I came up with the following solution, but I am wondering if I have 
overlooked something built-in?


function ToFarPointer(nearP: NearPointer) : FarPointer;
  var p: packed record ofs: NearPointer; segm: Word; end;
begin
  p.ofs := nearP;
  asm
    mov ax, seg @data
    mov [p.segm], ax
  end;
  ToFarPointer := FarPointer(p);
end;

(the above of course only works with the small / tiny / compact memory 
models)


Greetings, Bernd




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel