I have recently bought Borland C++ 5.0 which was the
last version that supported a 16-bit target.

I have looked through the included documentation,
and I can't find any way to get the default pointer
size/type to be huge instead of far (as both
Microsoft and Watcom do).

They appear to have full support for huge pointers
in the compiler (even back to Turbo C 2.0), you just
can't get it to default.

So all the logic is there, and there is probably just a
few bytes of code (preferably in the (now) freely
available Turbo C 2.0 or Turbo C++ 1.0) that need to
be zapped to make the default (and indeed - only)
pointer type to be huge instead of far - if you know
where to zap it.

I asked the pdcc author whether it was possible to
make the (way incomplete) compiler be at least good
enough to automatically convert "char *x" to
"char huge *x" in all pointer declarations.

Also char **x would need to be char huge * huge *x.

He doesn't have a simple answer to that question, but
he was surprised that there wasn't an existing workaround.

I actually bought Turbo C 2.0 in about 1988. I didn't actually
know what "huge" was until a few years ago.

If I had know this at the time I could have rung Borland and
asked for this enhancement before they went broke.

Was there some workaround in the decade or whatever
that this was being used? To be competitive with
Microsoft in this respect?

Thanks. Paul.

Paul Edwards ha scritto:
> I have recently bought Borland C++ 5.0 which was the
> last version that supported a 16-bit target.
>
> I have looked through the included documentation,
> and I can't find any way to get the default pointer
> size/type to be huge instead of far (as both
> Microsoft and Watcom do).
>
> They appear to have full support for huge pointers
> in the compiler (even back to Turbo C 2.0), you just
> can't get it to default.
>
> So all the logic is there, and there is probably just a
> few bytes of code (preferably in the (now) freely
> available Turbo C 2.0 or Turbo C++ 1.0) that need to
> be zapped to make the default (and indeed - only)
> pointer type to be huge instead of far - if you know
> where to zap it.
>
> I asked the pdcc author whether it was possible to
> make the (way incomplete) compiler be at least good
> enough to automatically convert "char *x" to
> "char huge *x" in all pointer declarations.
>
> Also char **x would need to be char huge * huge *x.
>
> He doesn't have a simple answer to that question, but
> he was surprised that there wasn't an existing workaround.
>
> I actually bought Turbo C 2.0 in about 1988. I didn't actually
> know what "huge" was until a few years ago.
>
> If I had know this at the time I could have rung Borland and
> asked for this enhancement before they went broke.
>
> Was there some workaround in the decade or whatever
> that this was being used? To be competitive with
> Microsoft in this respect?
>
> Thanks. Paul.
>

HI,
First of all I apologize in advance because I'm not sure I understand
the question but I try to answer the same.
The huge pointers can be used exactly like the far pointers and
have the same size. In a far Pointer the most significant 16 bits
represent the segment and the remaining 16 the offset but increasing a
far pointer beyond the offet limit you will get a rollover of the offset
on the same segment while with the huge pointer the segment will be
recalculated to allow you to advance In memory beyond the limit of the
segment size. Obviously, given the extra work, using a huge pointer will
be slower.

jak ha scritto:
> Paul Edwards ha scritto:
>> I have recently bought Borland C++ 5.0 which was the
>> last version that supported a 16-bit target.
>>
>> I have looked through the included documentation,
>> and I can't find any way to get the default pointer
>> size/type to be huge instead of far (as both
>> Microsoft and Watcom do).
>>
>> They appear to have full support for huge pointers
>> in the compiler (even back to Turbo C 2.0), you just
>> can't get it to default.
>>
>> So all the logic is there, and there is probably just a
>> few bytes of code (preferably in the (now) freely
>> available Turbo C 2.0 or Turbo C++ 1.0) that need to
>> be zapped to make the default (and indeed - only)
>> pointer type to be huge instead of far - if you know
>> where to zap it.
>>
>> I asked the pdcc author whether it was possible to
>> make the (way incomplete) compiler be at least good
>> enough to automatically convert "char *x" to
>> "char huge *x" in all pointer declarations.
>>
>> Also char **x would need to be char huge * huge *x.
>>
>> He doesn't have a simple answer to that question, but
>> he was surprised that there wasn't an existing workaround.
>>
>> I actually bought Turbo C 2.0 in about 1988. I didn't actually
>> know what "huge" was until a few years ago.
>>
>> If I had know this at the time I could have rung Borland and
>> asked for this enhancement before they went broke.
>>
>> Was there some workaround in the decade or whatever
>> that this was being used? To be competitive with
>> Microsoft in this respect?
>>
>> Thanks. Paul.
>>
>
> HI,
> First of all I apologize in advance because I'm not sure I understand
> the question but I try to answer the same.
> The huge pointers can be used exactly like the far pointers and
> have the same size. In a far Pointer the most significant 16 bits
> represent the segment and the remaining 16 the offset but increasing a
> far pointer beyond the offet limit you will get a rollover of the offset
> on the same segment while with the huge pointer the segment will be
> recalculated to allow you to advance In memory beyond the limit of the
> segment size. Obviously, given the extra work, using a huge pointer will
> be slower.

I would like to add a comment. I don't know why you need to specify the
pointer type because I remember it being necessary in rare cases, for
example when you wanted to write or read the video RAM directly, or when
it was necessary to interface with expanded or extended memory managers.
For the remainder of the cases, the necessary memory model was chosen.
These, if I remember correctly were 5: Tiny, Small, Medium, Compact,
Large and Huge. And if you need to use the huge model because, for
example, you expect that you will have to use arrays that are larger
than a segment (64k), then you will compile your code specifying the
memory model and in the code you will not need to specify a pointer of
type huge because all pointers will be huge. To be more clear:

char *ptr;

will be:
"near" (without segment) for the tiny, small and compact models
"far" for medium and large models
"huge" for the huge model

I hope what I wrote is readable.

On 9/14/23 9:12 AM, jak wrote:
> jak ha scritto:
>> Paul Edwards ha scritto:
>>> I have recently bought Borland C++ 5.0 which was the
>>> last version that supported a 16-bit target.
>>>
>>> I have looked through the included documentation,
>>> and I can't find any way to get the default pointer
>>> size/type to be huge instead of far (as both
>>> Microsoft and Watcom do).
>>>
>>> They appear to have full support for huge pointers
>>> in the compiler (even back to Turbo C 2.0), you just
>>> can't get it to default.
>>>
>>> So all the logic is there, and there is probably just a
>>> few bytes of code (preferably in the (now) freely
>>> available Turbo C 2.0 or Turbo C++ 1.0) that need to
>>> be zapped to make the default (and indeed - only)
>>> pointer type to be huge instead of far - if you know
>>> where to zap it.
>>>
>>> I asked the pdcc author whether it was possible to
>>> make the (way incomplete) compiler be at least good
>>> enough to automatically convert "char *x" to
>>> "char huge *x" in all pointer declarations.
>>>
>>> Also char **x would need to be char huge * huge *x.
>>>
>>> He doesn't have a simple answer to that question, but
>>> he was surprised that there wasn't an existing workaround.
>>>
>>> I actually bought Turbo C 2.0 in about 1988. I didn't actually
>>> know what "huge" was until a few years ago.
>>>
>>> If I had know this at the time I could have rung Borland and
>>> asked for this enhancement before they went broke.
>>>
>>> Was there some workaround in the decade or whatever
>>> that this was being used? To be competitive with
>>> Microsoft in this respect?
>>>
>>> Thanks. Paul.
>>>
>>
>> HI,
>> First of all I apologize in advance because I'm not sure I understand
>> the question but I try to answer the same.
>> The huge pointers can be used exactly like the far pointers and
>> have the same size. In a far Pointer the most significant 16 bits
>> represent the segment and the remaining 16 the offset but increasing a
>> far pointer beyond the offet limit you will get a rollover of the offset
>> on the same segment while with the huge pointer the segment will be
>> recalculated to allow you to advance In memory beyond the limit of the
>> segment size. Obviously, given the extra work, using a huge pointer will
>> be slower.
>
> I would like to add a comment. I don't know why you need to specify the
> pointer type because I remember it being necessary in rare cases, for
> example when you wanted to write or read the video RAM directly, or when
> it was necessary to interface with expanded or extended memory managers.
> For the remainder of the cases, the necessary memory model was chosen.
> These, if I remember correctly were 5: Tiny, Small, Medium, Compact,
> Large and Huge. And if you need to use the huge model because, for
> example, you expect that you will have to use arrays that are larger
> than a segment (64k), then you will compile your code specifying the
> memory model and in the code you will not need to specify a pointer of
> type huge because all pointers will be huge. To be more clear:
>
> char *ptr;
>
> will be:
> "near" (without segment) for the tiny, small and compact models
> "far" for medium and large models
> "huge" for the huge model
>
> I hope what I wrote is readable.

My memory is a bit different.

The "Huge" program model put every static object in a module in
(potentially) a different data segment, while the "Large" program
module, every module put all its static objects in one segment, common
to the module, but each module had its own segment. Thus Large allowed
more than 64k of static objects total, but only 64k in a given module,
while Huge allowed more than 64k in any given module.

"Huge" pointers were different, and allowed a given object, which had to
be of array type, to become larger than 64k in size. It did this by
handling overflow in the addition of the offset part of the pointer, and
adjusting the offset when this happens. This model still required the
base fundamental object to be under 64k in size.

There was no model that defaulted pointers to "Huge", likely because
Huge pointers were inefficient and a program that needed this would only
need it in a few places.

Richard Damon ha scritto:
> On 9/14/23 9:12 AM, jak wrote:
>> jak ha scritto:
>>> Paul Edwards ha scritto:
>>>> I have recently bought Borland C++ 5.0 which was the
>>>> last version that supported a 16-bit target.
>>>>
>>>> I have looked through the included documentation,
>>>> and I can't find any way to get the default pointer
>>>> size/type to be huge instead of far (as both
>>>> Microsoft and Watcom do).
>>>>
>>>> They appear to have full support for huge pointers
>>>> in the compiler (even back to Turbo C 2.0), you just
>>>> can't get it to default.
>>>>
>>>> So all the logic is there, and there is probably just a
>>>> few bytes of code (preferably in the (now) freely
>>>> available Turbo C 2.0 or Turbo C++ 1.0) that need to
>>>> be zapped to make the default (and indeed - only)
>>>> pointer type to be huge instead of far - if you know
>>>> where to zap it.
>>>>
>>>> I asked the pdcc author whether it was possible to
>>>> make the (way incomplete) compiler be at least good
>>>> enough to automatically convert "char *x" to
>>>> "char huge *x" in all pointer declarations.
>>>>
>>>> Also char **x would need to be char huge * huge *x.
>>>>
>>>> He doesn't have a simple answer to that question, but
>>>> he was surprised that there wasn't an existing workaround.
>>>>
>>>> I actually bought Turbo C 2.0 in about 1988. I didn't actually
>>>> know what "huge" was until a few years ago.
>>>>
>>>> If I had know this at the time I could have rung Borland and
>>>> asked for this enhancement before they went broke.
>>>>
>>>> Was there some workaround in the decade or whatever
>>>> that this was being used? To be competitive with
>>>> Microsoft in this respect?
>>>>
>>>> Thanks. Paul.
>>>>
>>>
>>> HI,
>>> First of all I apologize in advance because I'm not sure I understand
>>> the question but I try to answer the same.
>>> The huge pointers can be used exactly like the far pointers and
>>> have the same size. In a far Pointer the most significant 16 bits
>>> represent the segment and the remaining 16 the offset but increasing a
>>> far pointer beyond the offet limit you will get a rollover of the offset
>>> on the same segment while with the huge pointer the segment will be
>>> recalculated to allow you to advance In memory beyond the limit of the
>>> segment size. Obviously, given the extra work, using a huge pointer will
>>> be slower.
>>
>> I would like to add a comment. I don't know why you need to specify the
>> pointer type because I remember it being necessary in rare cases, for
>> example when you wanted to write or read the video RAM directly, or when
>> it was necessary to interface with expanded or extended memory managers.
>> For the remainder of the cases, the necessary memory model was chosen.
>> These, if I remember correctly were 5: Tiny, Small, Medium, Compact,
>> Large and Huge. And if you need to use the huge model because, for
>> example, you expect that you will have to use arrays that are larger
>> than a segment (64k), then you will compile your code specifying the
>> memory model and in the code you will not need to specify a pointer of
>> type huge because all pointers will be huge. To be more clear:
>>
>> char *ptr;
>>
>> will be:
>> "near" (without segment) for the tiny, small and compact models
>> "far" for medium and large models
>> "huge" for the huge model
>>
>> I hope what I wrote is readable.
>
> My memory is a bit different.
>
> The "Huge" program model put every static object in a module in
> (potentially) a different data segment, while the "Large" program
> module, every module put all its static objects in one segment, common
> to the module, but each module had its own segment. Thus Large allowed
> more than 64k of static objects total, but only 64k in a given module,
> while Huge allowed more than 64k in any given module.
>
> "Huge" pointers were different, and allowed a given object, which had to
> be of array type, to become larger than 64k in size. It did this by
> handling overflow in the addition of the offset part of the pointer, and
> adjusting the offset when this happens. This model still required the
> base fundamental object to be under 64k in size.
>
> There was no model that defaulted pointers to "Huge", likely because
> Huge pointers were inefficient and a program that needed this would only
> need it in a few places.

I must admit that I do not know many versions of the compilers for
systems with 20bit addressing, Just Microsoft 4.0, 5.11 and Borland BCC
3.11 (which I still have on 3 -inch disks), so I don't know version 2.0
and not even 5.0, but they are enough Sure that B. (3.11) had an extra
memory model if compared with M. (5.11) and this is the Tiny Model. I
surfed the web and the version I know seems to have the Huge Memory
Model.
All large data were made static because the stack was very small and
shared the space with the heap. For same reason M. In version 5.x of the
compiler, stopped the push of the stucts in the stack when passed for
value to a function and began to push their handle only.
For the rest, I'm sorry but I don't understand what you mean by
"modules". Maybe you mean the code enclosed in the same source file?

On Friday, September 15, 2023 at 12:33:56 AM UTC+8, Richard Damon wrote:

> On 9/14/23 9:12 AM, jak wrote:
> > jak ha scritto:

Hi both.

Thanks for your replies.

> There was no model that defaulted pointers to "Huge", likely because
> Huge pointers were inefficient and a program that needed this would only
> need it in a few places.

It's easier to simply demonstrate with generated code
from what I currently have installed. Note that the reason
I want a decent huge memory model is because:

1. I want to address SOME data that is more than 64k
2. I don't what to pollute my C90 code with a non-standard
"huge" keyword in the various places that need it.
3. I don't want to find the various places that may need it.
4. Real world testing by someone who actually did real
world testing reported that huge memory model gives a
4% overhead, not 4000% like everyone seems to believe.
5. I don't even care if it is a 100% overhead. Someone who
cares can pollute the provided source code with
non-standard keywords and/or rewrite in assembler
and/or simply upgrade to a faster processor.

D:\scratch\zzz>type foo.c
char huge *foo(char huge *a)
{ return a + 5;
}

D:\scratch\zzz>bcc -mh -S foo.c
Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
foo.c:

D:\scratch\zzz>

;
; char huge *foo(char huge *a)
;
push bp
mov bp,sp
push ds
mov ax,FOO_DATA
mov ds,ax
;
; {
; return a + 5;
;
mov dx,word ptr [bp+8]
mov ax,word ptr [bp+6]
xor cx,cx
mov bx,5
call far ptr F_PADD@
;
; }
;
pop ds
pop bp
ret

D:\scratch\zzz>type foo.c
char *foo(char *a)
{ return a + 5;
}

D:\scratch\zzz>bcc -mh -S foo.c
Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
foo.c:

D:\scratch\zzz>

; char *foo(char *a)
;
push bp
mov bp,sp
;
; {
; return a + 5;
;
mov dx,word ptr [bp+8]
mov ax,word ptr [bp+6]
add ax,5
;
; }
;
pop bp
ret

D:\scratch\zzz>\msvc15\bin\cl -S -AH -Ox foo.c
Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.

foo.c

D:\scratch\zzz>

_foo PROC FAR
; Line 2
push bp
mov bp,sp
; a = 6
; Line 3
mov ax,WORD PTR [bp+6] ;a
mov dx,WORD PTR [bp+8]
add ax,5
sbb cx,cx
and cx,OFFSET __AHINCR
add dx,cx
; Line 4
pop bp
ret

D:\scratch\zzz>wcl -mh -c foo.c
Open Watcom C/C++16 Compile and Link Utility Version 1.6
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wcc foo.c -mh
Open Watcom C16 Optimizing Compiler Version 1.6
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
foo.c: 4 lines, 0 warnings, 0 errors
Code size: 25

D:\scratch\zzz>

D:\scratch\zzz>wdis foo.obj
Module: D:\scratch\zzz\foo.c
GROUP: 'DGROUP' CONST,CONST2,_DATA

Segment: foo_TEXT BYTE USE16 00000019 bytes
0000 foo_:
0000 50 push ax
0001 B8 08 00 mov ax,0x0008
0004 9A 00 00 00 00 call __STK
0009 58 pop ax
000A 53 push bx
000B 51 push cx
000C BB 05 00 mov bx,0x0005
000F 31 C9 xor cx,cx
0011 9A 00 00 00 00 call __PIA
0016 59 pop cx
0017 5B pop bx
0018 CB retf

So - Microsoft has a variable fit for purpose, and Watcom has
a function call fit for purpose.

Borland has a function call fit for purpose only if you add
the "huge" keyword to every pointer declaration.

BFN. Paul.

Paul Edwards ha scritto:
> On Friday, September 15, 2023 at 12:33:56 AM UTC+8, Richard Damon wrote:
>
>> On 9/14/23 9:12 AM, jak wrote:
>>> jak ha scritto:
>
> Hi both.
>
> Thanks for your replies.
>
>> There was no model that defaulted pointers to "Huge", likely because
>> Huge pointers were inefficient and a program that needed this would only
>> need it in a few places.
>
> It's easier to simply demonstrate with generated code
> from what I currently have installed. Note that the reason
> I want a decent huge memory model is because:
>
> 1. I want to address SOME data that is more than 64k
> 2. I don't what to pollute my C90 code with a non-standard
> "huge" keyword in the various places that need it.
> 3. I don't want to find the various places that may need it.
> 4. Real world testing by someone who actually did real
> world testing reported that huge memory model gives a
> 4% overhead, not 4000% like everyone seems to believe.
> 5. I don't even care if it is a 100% overhead. Someone who
> cares can pollute the provided source code with
> non-standard keywords and/or rewrite in assembler
> and/or simply upgrade to a faster processor.
>
>
> D:\scratch\zzz>type foo.c
> char huge *foo(char huge *a)
> {
> return a + 5;
> }
>
> D:\scratch\zzz>bcc -mh -S foo.c
> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> foo.c:
>
> D:\scratch\zzz>
>
>
> ;
> ; char huge *foo(char huge *a)
> ;
> push bp
> mov bp,sp
> push ds
> mov ax,FOO_DATA
> mov ds,ax
> ;
> ; {
> ; return a + 5;
> ;
> mov dx,word ptr [bp+8]
> mov ax,word ptr [bp+6]
> xor cx,cx
> mov bx,5
> call far ptr F_PADD@
> ;
> ; }
> ;
> pop ds
> pop bp
> ret
>
>
>
>
> D:\scratch\zzz>type foo.c
> char *foo(char *a)
> {
> return a + 5;
> }
>
> D:\scratch\zzz>bcc -mh -S foo.c
> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> foo.c:
>
> D:\scratch\zzz>
>
>
> ; char *foo(char *a)
> ;
> push bp
> mov bp,sp
> ;
> ; {
> ; return a + 5;
> ;
> mov dx,word ptr [bp+8]
> mov ax,word ptr [bp+6]
> add ax,5
> ;
> ; }
> ;
> pop bp
> ret
>
>
>
> D:\scratch\zzz>\msvc15\bin\cl -S -AH -Ox foo.c
> Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
> Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
>
> foo.c
>
> D:\scratch\zzz>
>
>
> _foo PROC FAR
> ; Line 2
> push bp
> mov bp,sp
> ; a = 6
> ; Line 3
> mov ax,WORD PTR [bp+6] ;a
> mov dx,WORD PTR [bp+8]
> add ax,5
> sbb cx,cx
> and cx,OFFSET __AHINCR
> add dx,cx
> ; Line 4
> pop bp
> ret
>
>
>
> D:\scratch\zzz>wcl -mh -c foo.c
> Open Watcom C/C++16 Compile and Link Utility Version 1.6
> Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> See http://www.openwatcom.org/ for details.
> wcc foo.c -mh
> Open Watcom C16 Optimizing Compiler Version 1.6
> Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> See http://www.openwatcom.org/ for details.
> foo.c: 4 lines, 0 warnings, 0 errors
> Code size: 25
>
> D:\scratch\zzz>
>
>
> D:\scratch\zzz>wdis foo.obj
> Module: D:\scratch\zzz\foo.c
> GROUP: 'DGROUP' CONST,CONST2,_DATA
>
> Segment: foo_TEXT BYTE USE16 00000019 bytes
> 0000 foo_:
> 0000 50 push ax
> 0001 B8 08 00 mov ax,0x0008
> 0004 9A 00 00 00 00 call __STK
> 0009 58 pop ax
> 000A 53 push bx
> 000B 51 push cx
> 000C BB 05 00 mov bx,0x0005
> 000F 31 C9 xor cx,cx
> 0011 9A 00 00 00 00 call __PIA
> 0016 59 pop cx
> 0017 5B pop bx
> 0018 CB retf
>
>
> So - Microsoft has a variable fit for purpose, and Watcom has
> a function call fit for purpose.
>
> Borland has a function call fit for purpose only if you add
> the "huge" keyword to every pointer declaration.
>
> BFN. Paul.
>

mmmh ... there is something that does not convince me but unfortunately
I don't have an environment to perform a test. Could you do it for me?
I do not convince me that both functions the one with Huge in the
declaration of the function and the one without ending with 'ret' while
the one with Huge should end with 'retf'. Could you recompile with BCC
completely disabling the optimizer?
(Forgive my request)

On Friday, September 15, 2023 at 10:31:08 PM UTC+8, jak wrote:
> Paul Edwards ha scritto:
> > On Friday, September 15, 2023 at 12:33:56 AM UTC+8, Richard Damon wrote:
> >
> >> On 9/14/23 9:12 AM, jak wrote:
> >>> jak ha scritto:
> >
> > Hi both.
> >
> > Thanks for your replies.
> >
> >> There was no model that defaulted pointers to "Huge", likely because
> >> Huge pointers were inefficient and a program that needed this would only
> >> need it in a few places.
> >
> > It's easier to simply demonstrate with generated code
> > from what I currently have installed. Note that the reason
> > I want a decent huge memory model is because:
> >
> > 1. I want to address SOME data that is more than 64k
> > 2. I don't what to pollute my C90 code with a non-standard
> > "huge" keyword in the various places that need it.
> > 3. I don't want to find the various places that may need it.
> > 4. Real world testing by someone who actually did real
> > world testing reported that huge memory model gives a
> > 4% overhead, not 4000% like everyone seems to believe.
> > 5. I don't even care if it is a 100% overhead. Someone who
> > cares can pollute the provided source code with
> > non-standard keywords and/or rewrite in assembler
> > and/or simply upgrade to a faster processor.
> >
> >
> > D:\scratch\zzz>type foo.c
> > char huge *foo(char huge *a)
> > {
> > return a + 5;
> > }
> >
> > D:\scratch\zzz>bcc -mh -S foo.c
> > Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> > foo.c:
> >
> > D:\scratch\zzz>
> >
> >
> > ;
> > ; char huge *foo(char huge *a)
> > ;
> > push bp
> > mov bp,sp
> > push ds
> > mov ax,FOO_DATA
> > mov ds,ax
> > ;
> > ; {
> > ; return a + 5;
> > ;
> > mov dx,word ptr [bp+8]
> > mov ax,word ptr [bp+6]
> > xor cx,cx
> > mov bx,5
> > call far ptr F_PADD@
> > ;
> > ; }
> > ;
> > pop ds
> > pop bp
> > ret
> >
> >
> >
> >
> > D:\scratch\zzz>type foo.c
> > char *foo(char *a)
> > {
> > return a + 5;
> > }
> >
> > D:\scratch\zzz>bcc -mh -S foo.c
> > Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> > foo.c:
> >
> > D:\scratch\zzz>
> >
> >
> > ; char *foo(char *a)
> > ;
> > push bp
> > mov bp,sp
> > ;
> > ; {
> > ; return a + 5;
> > ;
> > mov dx,word ptr [bp+8]
> > mov ax,word ptr [bp+6]
> > add ax,5
> > ;
> > ; }
> > ;
> > pop bp
> > ret
> >
> >
> >
> > D:\scratch\zzz>\msvc15\bin\cl -S -AH -Ox foo.c
> > Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
> > Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
> >
> > foo.c
> >
> > D:\scratch\zzz>
> >
> >
> > _foo PROC FAR
> > ; Line 2
> > push bp
> > mov bp,sp
> > ; a = 6
> > ; Line 3
> > mov ax,WORD PTR [bp+6] ;a
> > mov dx,WORD PTR [bp+8]
> > add ax,5
> > sbb cx,cx
> > and cx,OFFSET __AHINCR
> > add dx,cx
> > ; Line 4
> > pop bp
> > ret
> >
> >
> >
> > D:\scratch\zzz>wcl -mh -c foo.c
> > Open Watcom C/C++16 Compile and Link Utility Version 1.6
> > Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
> > Source code is available under the Sybase Open Watcom Public License.
> > See http://www.openwatcom.org/ for details.
> > wcc foo.c -mh
> > Open Watcom C16 Optimizing Compiler Version 1.6
> > Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
> > Source code is available under the Sybase Open Watcom Public License.
> > See http://www.openwatcom.org/ for details.
> > foo.c: 4 lines, 0 warnings, 0 errors
> > Code size: 25
> >
> > D:\scratch\zzz>
> >
> >
> > D:\scratch\zzz>wdis foo.obj
> > Module: D:\scratch\zzz\foo.c
> > GROUP: 'DGROUP' CONST,CONST2,_DATA
> >
> > Segment: foo_TEXT BYTE USE16 00000019 bytes
> > 0000 foo_:
> > 0000 50 push ax
> > 0001 B8 08 00 mov ax,0x0008
> > 0004 9A 00 00 00 00 call __STK
> > 0009 58 pop ax
> > 000A 53 push bx
> > 000B 51 push cx
> > 000C BB 05 00 mov bx,0x0005
> > 000F 31 C9 xor cx,cx
> > 0011 9A 00 00 00 00 call __PIA
> > 0016 59 pop cx
> > 0017 5B pop bx
> > 0018 CB retf
> >
> >
> > So - Microsoft has a variable fit for purpose, and Watcom has
> > a function call fit for purpose.
> >
> > Borland has a function call fit for purpose only if you add
> > the "huge" keyword to every pointer declaration.
> >
> > BFN. Paul.
> >
> mmmh ... there is something that does not convince me but unfortunately
> I don't have an environment to perform a test. Could you do it for me?
> I do not convince me that both functions the one with Huge in the
> declaration of the function and the one without ending with 'ret' while
> the one with Huge should end with 'retf'.

This is normal - I didn't show the full assembler.

_foo PROC FAR

or

..model huge etc

in the assembler will convert a ret to retf automatically (in a proc).

> Could you recompile with BCC
> completely disabling the optimizer?
> (Forgive my request)

I didn't use the optimizer with bcc. ie if you look at the
command line above, I don't have a "-O-anything".

BFN. Paul.

D:\scratch\zzz>bcc
Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
Syntax is: BCC [ options ] file[s] * = default; -x- = turn switch x off
-1 80186/286 Instructions -2 * 80286 Protected Mode Inst.
-3 80386 Instructions -Ax Disable extensions
-B Compile via assembly -C Allow nested comments
-Dxxx Define macro -Exxx Alternate Assembler name
-Hxxx Use pre-compiled headers -Ixxx Include files directory
-K Default char is unsigned -Lxxx Libraries directory
-M Generate link map -N Check stack overflow
-Ox Optimizations -P Force C++ compile
-R Produce browser info -RT * Generate RTTI
-S Produce assembly output -Txxx Set assembler option
-Uxxx Undefine macro -Vx Virtual table control
-X Suppress autodep. output -Yx Overlay control
-Z Suppress register reloads -aN Align on N bytes
-b * Treat enums as integers -c Compile only
-d Merge duplicate strings -exxx Executable file name
-fxx Floating point options -gN Stop after N warnings
-iN Max. identifier length -jN Stop after N errors
-k * Standard stack frame -lx Set linker option
-mx Set Memory Model -nxxx Output file directory
-oxxx Object file name -p Pascal calls
-po fastthis calls -tWxxx Create Windows app
-u * Underscores on externs -v Source level debugging
-wxxx Warning control -xxxx Exception handling
-y Produce line number info -zxxx Set segment names

D:\scratch\zzz>

Paul Edwards ha scritto:
> On Friday, September 15, 2023 at 10:31:08 PM UTC+8, jak wrote:
>> Paul Edwards ha scritto:
>>> On Friday, September 15, 2023 at 12:33:56 AM UTC+8, Richard Damon wrote:
>>>
>>>> On 9/14/23 9:12 AM, jak wrote:
>>>>> jak ha scritto:
>>>
>>> Hi both.
>>>
>>> Thanks for your replies.
>>>
>>>> There was no model that defaulted pointers to "Huge", likely because
>>>> Huge pointers were inefficient and a program that needed this would only
>>>> need it in a few places.
>>>
>>> It's easier to simply demonstrate with generated code
>>> from what I currently have installed. Note that the reason
>>> I want a decent huge memory model is because:
>>>
>>> 1. I want to address SOME data that is more than 64k
>>> 2. I don't what to pollute my C90 code with a non-standard
>>> "huge" keyword in the various places that need it.
>>> 3. I don't want to find the various places that may need it.
>>> 4. Real world testing by someone who actually did real
>>> world testing reported that huge memory model gives a
>>> 4% overhead, not 4000% like everyone seems to believe.
>>> 5. I don't even care if it is a 100% overhead. Someone who
>>> cares can pollute the provided source code with
>>> non-standard keywords and/or rewrite in assembler
>>> and/or simply upgrade to a faster processor.
>>>
>>>
>>> D:\scratch\zzz>type foo.c
>>> char huge *foo(char huge *a)
>>> {
>>> return a + 5;
>>> }
>>>
>>> D:\scratch\zzz>bcc -mh -S foo.c
>>> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
>>> foo.c:
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> ;
>>> ; char huge *foo(char huge *a)
>>> ;
>>> push bp
>>> mov bp,sp
>>> push ds
>>> mov ax,FOO_DATA
>>> mov ds,ax
>>> ;
>>> ; {
>>> ; return a + 5;
>>> ;
>>> mov dx,word ptr [bp+8]
>>> mov ax,word ptr [bp+6]
>>> xor cx,cx
>>> mov bx,5
>>> call far ptr F_PADD@
>>> ;
>>> ; }
>>> ;
>>> pop ds
>>> pop bp
>>> ret
>>>
>>>
>>>
>>>
>>> D:\scratch\zzz>type foo.c
>>> char *foo(char *a)
>>> {
>>> return a + 5;
>>> }
>>>
>>> D:\scratch\zzz>bcc -mh -S foo.c
>>> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
>>> foo.c:
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> ; char *foo(char *a)
>>> ;
>>> push bp
>>> mov bp,sp
>>> ;
>>> ; {
>>> ; return a + 5;
>>> ;
>>> mov dx,word ptr [bp+8]
>>> mov ax,word ptr [bp+6]
>>> add ax,5
>>> ;
>>> ; }
>>> ;
>>> pop bp
>>> ret
>>>
>>>
>>>
>>> D:\scratch\zzz>\msvc15\bin\cl -S -AH -Ox foo.c
>>> Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
>>> Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
>>>
>>> foo.c
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> _foo PROC FAR
>>> ; Line 2
>>> push bp
>>> mov bp,sp
>>> ; a = 6
>>> ; Line 3
>>> mov ax,WORD PTR [bp+6] ;a
>>> mov dx,WORD PTR [bp+8]
>>> add ax,5
>>> sbb cx,cx
>>> and cx,OFFSET __AHINCR
>>> add dx,cx
>>> ; Line 4
>>> pop bp
>>> ret
>>>
>>>
>>>
>>> D:\scratch\zzz>wcl -mh -c foo.c
>>> Open Watcom C/C++16 Compile and Link Utility Version 1.6
>>> Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
>>> Source code is available under the Sybase Open Watcom Public License.
>>> See http://www.openwatcom.org/ for details.
>>> wcc foo.c -mh
>>> Open Watcom C16 Optimizing Compiler Version 1.6
>>> Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
>>> Source code is available under the Sybase Open Watcom Public License.
>>> See http://www.openwatcom.org/ for details.
>>> foo.c: 4 lines, 0 warnings, 0 errors
>>> Code size: 25
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> D:\scratch\zzz>wdis foo.obj
>>> Module: D:\scratch\zzz\foo.c
>>> GROUP: 'DGROUP' CONST,CONST2,_DATA
>>>
>>> Segment: foo_TEXT BYTE USE16 00000019 bytes
>>> 0000 foo_:
>>> 0000 50 push ax
>>> 0001 B8 08 00 mov ax,0x0008
>>> 0004 9A 00 00 00 00 call __STK
>>> 0009 58 pop ax
>>> 000A 53 push bx
>>> 000B 51 push cx
>>> 000C BB 05 00 mov bx,0x0005
>>> 000F 31 C9 xor cx,cx
>>> 0011 9A 00 00 00 00 call __PIA
>>> 0016 59 pop cx
>>> 0017 5B pop bx
>>> 0018 CB retf
>>>
>>>
>>> So - Microsoft has a variable fit for purpose, and Watcom has
>>> a function call fit for purpose.
>>>
>>> Borland has a function call fit for purpose only if you add
>>> the "huge" keyword to every pointer declaration.
>>>
>>> BFN. Paul.
>>>
>> mmmh ... there is something that does not convince me but unfortunately
>> I don't have an environment to perform a test. Could you do it for me?
>> I do not convince me that both functions the one with Huge in the
>> declaration of the function and the one without ending with 'ret' while
>> the one with Huge should end with 'retf'.
>
> This is normal - I didn't show the full assembler.
>
> _foo PROC FAR
>
> or
>
> .model huge etc
>
> in the assembler will convert a ret to retf automatically (in a proc).
>
>> Could you recompile with BCC
>> completely disabling the optimizer?
>> (Forgive my request)
>
> I didn't use the optimizer with bcc. ie if you look at the
> command line above, I don't have a "-O-anything".
>
> BFN. Paul.
>
>
>
> D:\scratch\zzz>bcc
> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> Syntax is: BCC [ options ] file[s] * = default; -x- = turn switch x off
> -1 80186/286 Instructions -2 * 80286 Protected Mode Inst.
> -3 80386 Instructions -Ax Disable extensions
> -B Compile via assembly -C Allow nested comments
> -Dxxx Define macro -Exxx Alternate Assembler name
> -Hxxx Use pre-compiled headers -Ixxx Include files directory
> -K Default char is unsigned -Lxxx Libraries directory
> -M Generate link map -N Check stack overflow
> -Ox Optimizations -P Force C++ compile
> -R Produce browser info -RT * Generate RTTI
> -S Produce assembly output -Txxx Set assembler option
> -Uxxx Undefine macro -Vx Virtual table control
> -X Suppress autodep. output -Yx Overlay control
> -Z Suppress register reloads -aN Align on N bytes
> -b * Treat enums as integers -c Compile only
> -d Merge duplicate strings -exxx Executable file name
> -fxx Floating point options -gN Stop after N warnings
> -iN Max. identifier length -jN Stop after N errors
> -k * Standard stack frame -lx Set linker option
> -mx Set Memory Model -nxxx Output file directory
> -oxxx Object file name -p Pascal calls
> -po fastthis calls -tWxxx Create Windows app
> -u * Underscores on externs -v Source level debugging
> -wxxx Warning control -xxxx Exception handling
> -y Produce line number info -zxxx Set segment names
>
> D:\scratch\zzz>
>
The option to disable optimizations should be '-Od'. Below I am
attaching the list of optimization flags that should be available in
your compiler:

-02 Options - Compiler - Optimizations - Full Speed
-Ox Generates the fastest code possible. This is the same as using the
following
command-line options: -0 -Ob -Oe -Og -Oi -Ol-Om -Op -Ot -Ov -k- -Z
-01 Options - Compiler - Optimizations - Full Size
Generates the smallest code possible. This is the same as using the
following
command-line options: -0 -Ob -Oe -Ol-Os -k- -Z
-0 Options - Compiler - Optimizations - Optimize Jumps
Removes jumps to jumps, unreachable code, and unnecessary jumps
-Oa Options - Compiler - Optimizations - Assume no pointer aliasing
Assume that pointer expressions are not aliased in common subexpression
evaluation
-Ob Options - Compiler - Optimizations - Dead code elimination
Eliminates stores into dead variables and conditional expressions
whose values
can be determined at compiletime
-Oc Options - Compiler - Optimizations - Common Subexpressions -
Optimize locally
Enables common sub expression elimination within basic blocks only.
The -Oc
option and the -Og option are mutually exclusive
-Od Options - Compiler - Optimizations - No Optimizing
Disables all optimizations. Note that this is not the same as -0-,
which merely
disables jump optimizations. It is equivalent to -O-cgbelmvpi -Z-
-0-. Also
note that this option doesn't change the code-generation options
for size (-Os)
or speed (-0).
-Oe Options - Compiler - Optimizations - Global register allocation
Enables global register allocation and variable live range analysis
-Og Options - Compiler - Optimizations - Common Sub expressions -
Optimize globally
Enables common sub expression elimination within an entire
function. The -Og
option and the -Oc option are mutually exclusive
-Oi Options - Compiler - Optimizations - Inline intrinsics
Enables inlining of intrinsic functions such as memcpy, strlen, etc.
-01 Options - Compiler - Optimizations - Loop optimization
Compacts loops into REP /STOSx instructions
-Om Options - Compiler - Optimizations - Invariant code motion
Moves invariant code out of loops
-Op Options - Compiler - Optimizations - Copy propagation
Propagates copies of constants, variables, and expressions where
possible
-Os Options - Compiler - Optimizations - Optimize for - Size
Makes code-selection choices in favor of smaller code
-Ot Options - Compiler - Optimizations - Optimize for - Speed
Selects code in favor of executable speed
-Ov Options - Compiler - Optimizations - Induction Variables
Enables loop-induction variable and strength-reduction optimizations
-Z Options - Compiler - Optimizations - Suppress redundant loads
Suppresses reloads of values which are already in registers
-po Options - Compiler - Optimizations - Object Data Calling
Enables the use of the Object Data calling convention for passing
this in a
register to member functions.
-pr Options - Compiler - Entry /Exit Code - Calling Convention - Register
Enables the use of the _fastcall calling convention for passing
parameters in
registers

jak <nospam@please.ty> writes:

> The option to disable optimizations should be '-Od'. Below I am
> attaching the list of optimization flags that should be available in
> your compiler:

Is this for the Borland C compiler? Do some of the optimisation flags
really start with -O and some with -0:

> -02 Options - Compiler - Optimizations - Full Speed
> -Ox Generates the fastest code possible. This is the same as using the
> following
> command-line options: -0 -Ob -Oe -Og -Oi -Ol-Om -Op -Ot -Ov -k- -Z
> -01 Options - Compiler - Optimizations - Full Size
> Generates the smallest code possible. This is the same as using the
> following
> command-line options: -0 -Ob -Oe -Ol-Os -k- -Z
> -0 Options - Compiler - Optimizations - Optimize Jumps
> Removes jumps to jumps, unreachable code, and unnecessary jumps
> -Oa Options - Compiler - Optimizations - Assume no pointer aliasing
> Assume that pointer expressions are not aliased in common subexpression
> evaluation

etc...

There's no logical reason why not, but it does seem peculiar and
potentially confusing.

--
Ben.

Ben Bacarisse ha scritto:
> jak <nospam@please.ty> writes:
>
>> The option to disable optimizations should be '-Od'. Below I am
>> attaching the list of optimization flags that should be available in
>> your compiler:
>
> Is this for the Borland C compiler? Do some of the optimisation flags
> really start with -O and some with -0:
>
>> -02 Options - Compiler - Optimizations - Full Speed
>> -Ox Generates the fastest code possible. This is the same as using the
>> following
>> command-line options: -0 -Ob -Oe -Og -Oi -Ol-Om -Op -Ot -Ov -k- -Z
>> -01 Options - Compiler - Optimizations - Full Size
>> Generates the smallest code possible. This is the same as using the
>> following
>> command-line options: -0 -Ob -Oe -Ol-Os -k- -Z
>> -0 Options - Compiler - Optimizations - Optimize Jumps
>> Removes jumps to jumps, unreachable code, and unnecessary jumps
>> -Oa Options - Compiler - Optimizations - Assume no pointer aliasing
>> Assume that pointer expressions are not aliased in common subexpression
>> evaluation
>
> etc...
>
> There's no logical reason why not, but it does seem peculiar and
> potentially confusing.
>

I think it's corrected because I didn't write by hand. This is a
copy&paste from an old .chm help file.

Paul Edwards ha scritto:
> On Friday, September 15, 2023 at 10:31:08 PM UTC+8, jak wrote:
>> Paul Edwards ha scritto:
>>> On Friday, September 15, 2023 at 12:33:56 AM UTC+8, Richard Damon wrote:
>>>
>>>> On 9/14/23 9:12 AM, jak wrote:
>>>>> jak ha scritto:
>>>
>>> Hi both.
>>>
>>> Thanks for your replies.
>>>
>>>> There was no model that defaulted pointers to "Huge", likely because
>>>> Huge pointers were inefficient and a program that needed this would only
>>>> need it in a few places.
>>>
>>> It's easier to simply demonstrate with generated code
>>> from what I currently have installed. Note that the reason
>>> I want a decent huge memory model is because:
>>>
>>> 1. I want to address SOME data that is more than 64k
>>> 2. I don't what to pollute my C90 code with a non-standard
>>> "huge" keyword in the various places that need it.
>>> 3. I don't want to find the various places that may need it.
>>> 4. Real world testing by someone who actually did real
>>> world testing reported that huge memory model gives a
>>> 4% overhead, not 4000% like everyone seems to believe.
>>> 5. I don't even care if it is a 100% overhead. Someone who
>>> cares can pollute the provided source code with
>>> non-standard keywords and/or rewrite in assembler
>>> and/or simply upgrade to a faster processor.
>>>
>>>
>>> D:\scratch\zzz>type foo.c
>>> char huge *foo(char huge *a)
>>> {
>>> return a + 5;
>>> }
>>>
>>> D:\scratch\zzz>bcc -mh -S foo.c
>>> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
>>> foo.c:
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> ;
>>> ; char huge *foo(char huge *a)
>>> ;
>>> push bp
>>> mov bp,sp
>>> push ds
>>> mov ax,FOO_DATA
>>> mov ds,ax
>>> ;
>>> ; {
>>> ; return a + 5;
>>> ;
>>> mov dx,word ptr [bp+8]
>>> mov ax,word ptr [bp+6]
>>> xor cx,cx
>>> mov bx,5
>>> call far ptr F_PADD@
>>> ;
>>> ; }
>>> ;
>>> pop ds
>>> pop bp
>>> ret
>>>
>>>
>>>
>>>
>>> D:\scratch\zzz>type foo.c
>>> char *foo(char *a)
>>> {
>>> return a + 5;
>>> }
>>>
>>> D:\scratch\zzz>bcc -mh -S foo.c
>>> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
>>> foo.c:
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> ; char *foo(char *a)
>>> ;
>>> push bp
>>> mov bp,sp
>>> ;
>>> ; {
>>> ; return a + 5;
>>> ;
>>> mov dx,word ptr [bp+8]
>>> mov ax,word ptr [bp+6]
>>> add ax,5
>>> ;
>>> ; }
>>> ;
>>> pop bp
>>> ret
>>>
>>>
>>>
>>> D:\scratch\zzz>\msvc15\bin\cl -S -AH -Ox foo.c
>>> Microsoft (R) C/C++ Optimizing Compiler Version 8.00c
>>> Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
>>>
>>> foo.c
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> _foo PROC FAR
>>> ; Line 2
>>> push bp
>>> mov bp,sp
>>> ; a = 6
>>> ; Line 3
>>> mov ax,WORD PTR [bp+6] ;a
>>> mov dx,WORD PTR [bp+8]
>>> add ax,5
>>> sbb cx,cx
>>> and cx,OFFSET __AHINCR
>>> add dx,cx
>>> ; Line 4
>>> pop bp
>>> ret
>>>
>>>
>>>
>>> D:\scratch\zzz>wcl -mh -c foo.c
>>> Open Watcom C/C++16 Compile and Link Utility Version 1.6
>>> Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
>>> Source code is available under the Sybase Open Watcom Public License.
>>> See http://www.openwatcom.org/ for details.
>>> wcc foo.c -mh
>>> Open Watcom C16 Optimizing Compiler Version 1.6
>>> Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
>>> Source code is available under the Sybase Open Watcom Public License.
>>> See http://www.openwatcom.org/ for details.
>>> foo.c: 4 lines, 0 warnings, 0 errors
>>> Code size: 25
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> D:\scratch\zzz>wdis foo.obj
>>> Module: D:\scratch\zzz\foo.c
>>> GROUP: 'DGROUP' CONST,CONST2,_DATA
>>>
>>> Segment: foo_TEXT BYTE USE16 00000019 bytes
>>> 0000 foo_:
>>> 0000 50 push ax
>>> 0001 B8 08 00 mov ax,0x0008
>>> 0004 9A 00 00 00 00 call __STK
>>> 0009 58 pop ax
>>> 000A 53 push bx
>>> 000B 51 push cx
>>> 000C BB 05 00 mov bx,0x0005
>>> 000F 31 C9 xor cx,cx
>>> 0011 9A 00 00 00 00 call __PIA
>>> 0016 59 pop cx
>>> 0017 5B pop bx
>>> 0018 CB retf
>>>
>>>
>>> So - Microsoft has a variable fit for purpose, and Watcom has
>>> a function call fit for purpose.
>>>
>>> Borland has a function call fit for purpose only if you add
>>> the "huge" keyword to every pointer declaration.
>>>
>>> BFN. Paul.
>>>
>> mmmh ... there is something that does not convince me but unfortunately
>> I don't have an environment to perform a test. Could you do it for me?
>> I do not convince me that both functions the one with Huge in the
>> declaration of the function and the one without ending with 'ret' while
>> the one with Huge should end with 'retf'.
>
> This is normal - I didn't show the full assembler.
>
> _foo PROC FAR
>
> or
>
> .model huge etc
>
> in the assembler will convert a ret to retf automatically (in a proc).
>
>> Could you recompile with BCC
>> completely disabling the optimizer?
>> (Forgive my request)
>
> I didn't use the optimizer with bcc. ie if you look at the
> command line above, I don't have a "-O-anything".
>
> BFN. Paul.
>
>
>
> D:\scratch\zzz>bcc
> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> Syntax is: BCC [ options ] file[s] * = default; -x- = turn switch x off
> -1 80186/286 Instructions -2 * 80286 Protected Mode Inst.
> -3 80386 Instructions -Ax Disable extensions
> -B Compile via assembly -C Allow nested comments
> -Dxxx Define macro -Exxx Alternate Assembler name
> -Hxxx Use pre-compiled headers -Ixxx Include files directory
> -K Default char is unsigned -Lxxx Libraries directory
> -M Generate link map -N Check stack overflow
> -Ox Optimizations -P Force C++ compile
> -R Produce browser info -RT * Generate RTTI
> -S Produce assembly output -Txxx Set assembler option
> -Uxxx Undefine macro -Vx Virtual table control
> -X Suppress autodep. output -Yx Overlay control
> -Z Suppress register reloads -aN Align on N bytes
> -b * Treat enums as integers -c Compile only
> -d Merge duplicate strings -exxx Executable file name
> -fxx Floating point options -gN Stop after N warnings
> -iN Max. identifier length -jN Stop after N errors
> -k * Standard stack frame -lx Set linker option
> -mx Set Memory Model -nxxx Output file directory
> -oxxx Object file name -p Pascal calls
> -po fastthis calls -tWxxx Create Windows app
> -u * Underscores on externs -v Source level debugging
> -wxxx Warning control -xxxx Exception handling
> -y Produce line number info -zxxx Set segment names
>
> D:\scratch\zzz>
>

I would also like to add another thing: it would be interesting to see
the disassembled of the .obj file produced by the Borland compiler as it
was done with that of Watcom. If 'wdis' cannot do it, you can find a
good disassembly with the freeware package 'nbasm'.
It could happen that the information that B. compiler saves in the .asm
file is sufficient to it to produce an .obj file similar to W.

Paul Edwards:

> I have recently bought Borland C++ 5.0 which was the last
> version that supported a 16-bit target.

Does one still have to buy it?

> I have looked through the included documentation, and I
> can't find any way to get the default pointer size/type to
> be huge instead of far (as both Microsoft and Watcom do).

A peek into the User's guide shows they have no concept of a
huge pointer, and only speak of huge and large /memory
models/ and huge pointer /operations/. See the -mh, -mh,
and -h switches:

-h Usually, Borland C++ normalizes a huge pointer whenever
adding or subtracting from it. This ensures, for
example, that if you have an array of structs that's
larger than 64K, indexing into the array and selecting a
struct field always works with structs of any size.
Borland C++ accomplishes this by always normalizing the
results of huge pointer operations-the address offset
contains a number that is no higher than 15 and a
segment wraparound never occurs with huge pointers. The
disadvantage of this approach is that it tends to be
quite expensive in terms of execution speed.

-mh Use the huge model for very large applications only. Far
pointers are used for both code and data. Borland C++
normally limits the size of all static data to 64K; the
huge memory model sets aside that limit, allowing data
to occupy more than 64K.

-ml Use the large model for very large applications only.
Far pointers are used for both code and data. Data is
limited to 1MB. Far pointers can point almost anywhere.
All functions and data pointers are far by default.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Hi guys - thanks for your responses and sorry for the delay.

On Sunday, September 17, 2023 at 5:02:35 AM UTC+8, Anton Shepelev wrote:

> > I have recently bought Borland C++ 5.0 which was the last
> > version that supported a 16-bit target.

> Does one still have to buy it?

If you want to be squeaky clean, yes.

I don't want 30 years of my life to be thrown away because
someone can accuse me of using pirated software to
develop PDOS.

I heard (I don't know if it is true) that Microsoft paid some
schmuck to write a book claiming (lying) that Linus stole
code from Minix or something like that.

Anyway, I've been buying heaps of stuff recently - mostly
Microsoft software. I have probably spend US$10k or
something on it. Most of it is showcased on my vlog at
http://pdos.org

Pouring over license agreements too.

Yesterday I spent all day trying to get Visual Studio 2003
to run on Windows 2000. I wanted to know if I could build
Hercules/380 and run it on Windows 95.

Result is a bit complicated - but so far no, I need winsock2
I think.

> > I have looked through the included documentation, and I
> > can't find any way to get the default pointer size/type to
> > be huge instead of far (as both Microsoft and Watcom do).

> A peek into the User's guide shows they have no concept of a
> huge pointer, and only speak of huge and large /memory
> models/ and huge pointer /operations/. See the -mh, -mh,
> and -h switches:

I don't know what you mean. The "huge" keyword exists and
generates the correct (desired) code.

Anyway, here is the extra info requested:

D:\scratch\zzz>type foo.c
char *foo(char *a)
{ return a + 5;
}

D:\scratch\zzz>bcc -Od -S -mh foo.c
Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
foo.c:

D:\scratch\zzz>

no change:

;
; char *foo(char *a)
;
push bp
mov bp,sp
;
; {
; return a + 5;
;
mov dx,word ptr [bp+8]
mov ax,word ptr [bp+6]
add ax,5
;
; }
;
pop bp
ret

D:\scratch\zzz>bcc -Od -c -mh foo.c
Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
foo.c:

D:\scratch\zzz>

D:\scratch\zzz>dir /od
Volume in drive D has no label.
Volume Serial Number is 9C33-6BBD

Directory of D:\scratch\zzz

2023-09-12 20:37 <DIR> ..
2023-09-12 20:37 <DIR> .
2023-09-14 11:48 76 fooadv.c
2023-09-15 18:53 55 foo.huge
2023-09-15 18:58 45 foo.c
2023-09-18 03:11 1,060 foo.asm
2023-09-18 03:12 199 foo.obj
5 File(s) 1,435 bytes
2 Dir(s) 7,364,018,176 bytes free

D:\scratch\zzz>wdis foo.obj
Module: foo.c

Segment: FOO_TEXT BYTE USE16 0000000E bytes
0000 _foo:
0000 55 push bp
0001 8B EC mov bp,sp
0003 8B 56 08 mov dx,word ptr 0x8[bp]
0006 8B 46 06 mov ax,word ptr 0x6[bp]
0009 05 05 00 add ax,0x0005
000C 5D pop bp
000D CB retf

Routine Size: 14 bytes, Routine Base: FOO_TEXT + 0000

No disassembly errors

Segment: FOO_DATA WORD USE16 00000000 bytes

D:\scratch\zzz>

D:\scratch\zzz>hexdump foo.obj
000000 80070005 666F6F2E 639F8818 00000014 ....foo.c.......
000010 54433836 20426F72 6C616E64 20432B2B TC86 Borland C++
000020 20352E30 F9880500 00F90301 76880D00 5.0........v...
000030 00E94697 2F570566 6F6F2E63 45880700 ..F./W.foo.cE...
000040 00FA0000 00007788 030000E9 8C880500 ......w.........
000050 00EA010D 7B962200 0008464F 4F5F5445 ....{."...FOO_TE
000060 58540443 4F444508 464F4F5F 44415441 XT.CODE.FOO_DATA
000070 08464152 5F444154 41DA9807 00280E00 .FAR_DATA....(..
000080 02030125 98070048 00000405 010F900B ...%...H........
000090 00000104 5F666F6F 000000BD A0120001 ...._foo........
0000A0 0000558B EC8B5608 8B460605 05005DCB ..U...V..F....].
0000B0 8F880E00 00E80105 666F6F2E 6346972F ........foo.cF./
0000C0 57448A02 000074 WD....t

D:\scratch\zzz>

BFN. Paul.

Paul Edwards ha scritto:
> Hi guys - thanks for your responses and sorry for the delay.
>
> On Sunday, September 17, 2023 at 5:02:35 AM UTC+8, Anton Shepelev wrote:
>
>>> I have recently bought Borland C++ 5.0 which was the last
>>> version that supported a 16-bit target.
>
>> Does one still have to buy it?
>
> If you want to be squeaky clean, yes.
>
> I don't want 30 years of my life to be thrown away because
> someone can accuse me of using pirated software to
> develop PDOS.
>
> I heard (I don't know if it is true) that Microsoft paid some
> schmuck to write a book claiming (lying) that Linus stole
> code from Minix or something like that.
>
> Anyway, I've been buying heaps of stuff recently - mostly
> Microsoft software. I have probably spend US$10k or
> something on it. Most of it is showcased on my vlog at
> http://pdos.org
>
> Pouring over license agreements too.
>
> Yesterday I spent all day trying to get Visual Studio 2003
> to run on Windows 2000. I wanted to know if I could build
> Hercules/380 and run it on Windows 95.
>
> Result is a bit complicated - but so far no, I need winsock2
> I think.
>
>>> I have looked through the included documentation, and I
>>> can't find any way to get the default pointer size/type to
>>> be huge instead of far (as both Microsoft and Watcom do).
>
>> A peek into the User's guide shows they have no concept of a
>> huge pointer, and only speak of huge and large /memory
>> models/ and huge pointer /operations/. See the -mh, -mh,
>> and -h switches:
>
> I don't know what you mean. The "huge" keyword exists and
> generates the correct (desired) code.
>
> Anyway, here is the extra info requested:
>
> D:\scratch\zzz>type foo.c
> char *foo(char *a)
> {
> return a + 5;
> }
>
> D:\scratch\zzz>bcc -Od -S -mh foo.c
> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> foo.c:
>
> D:\scratch\zzz>
>
> no change:
>
> ;
> ; char *foo(char *a)
> ;
> push bp
> mov bp,sp
> ;
> ; {
> ; return a + 5;
> ;
> mov dx,word ptr [bp+8]
> mov ax,word ptr [bp+6]
> add ax,5
> ;
> ; }
> ;
> pop bp
> ret
>
>
>
> D:\scratch\zzz>bcc -Od -c -mh foo.c
> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> foo.c:
>
> D:\scratch\zzz>
>
>
> D:\scratch\zzz>dir /od
> Volume in drive D has no label.
> Volume Serial Number is 9C33-6BBD
>
> Directory of D:\scratch\zzz
>
> 2023-09-12 20:37 <DIR> ..
> 2023-09-12 20:37 <DIR> .
> 2023-09-14 11:48 76 fooadv.c
> 2023-09-15 18:53 55 foo.huge
> 2023-09-15 18:58 45 foo.c
> 2023-09-18 03:11 1,060 foo.asm
> 2023-09-18 03:12 199 foo.obj
> 5 File(s) 1,435 bytes
> 2 Dir(s) 7,364,018,176 bytes free
>
> D:\scratch\zzz>wdis foo.obj
> Module: foo.c
>
> Segment: FOO_TEXT BYTE USE16 0000000E bytes
> 0000 _foo:
> 0000 55 push bp
> 0001 8B EC mov bp,sp
> 0003 8B 56 08 mov dx,word ptr 0x8[bp]
> 0006 8B 46 06 mov ax,word ptr 0x6[bp]
> 0009 05 05 00 add ax,0x0005
> 000C 5D pop bp
> 000D CB retf
>
> Routine Size: 14 bytes, Routine Base: FOO_TEXT + 0000
>
> No disassembly errors
>
> Segment: FOO_DATA WORD USE16 00000000 bytes
>
>
> D:\scratch\zzz>
>
>
>
> D:\scratch\zzz>hexdump foo.obj
> 000000 80070005 666F6F2E 639F8818 00000014 ....foo.c.......
> 000010 54433836 20426F72 6C616E64 20432B2B TC86 Borland C++
> 000020 20352E30 F9880500 00F90301 76880D00 5.0........v...
> 000030 00E94697 2F570566 6F6F2E63 45880700 ..F./W.foo.cE...
> 000040 00FA0000 00007788 030000E9 8C880500 ......w.........
> 000050 00EA010D 7B962200 0008464F 4F5F5445 ....{."...FOO_TE
> 000060 58540443 4F444508 464F4F5F 44415441 XT.CODE.FOO_DATA
> 000070 08464152 5F444154 41DA9807 00280E00 .FAR_DATA....(..
> 000080 02030125 98070048 00000405 010F900B ...%...H........
> 000090 00000104 5F666F6F 000000BD A0120001 ...._foo........
> 0000A0 0000558B EC8B5608 8B460605 05005DCB ..U...V..F....].
> 0000B0 8F880E00 00E80105 666F6F2E 6346972F ........foo.cF./
> 0000C0 57448A02 000074 WD....t
>
> D:\scratch\zzz>
>
>
> BFN. Paul.
>

I admit I am surprised. It is evident that the compiler correctly
interprets the memory model (-mh) in fact in the disassembled the
function ends with the 'retf'. The only thing that comes to mind by
observing the code of the function is that, in fact, it does not
need to recalculate the address that it returns (e.g. 1234:0 -> 1234:5).
Would you like to do a test for me again?

char *foo(char *a)
{ return a + 65600;
}

In this way it should be obliged to recalculate. With the value 65600 I
wanted to exaggerate because I think that 0x10 could be enough (greater
than the less significant nibble of the offset).

On Monday, September 18, 2023 at 4:33:31 AM UTC+8, jak wrote:
> Paul Edwards ha scritto:
> > Hi guys - thanks for your responses and sorry for the delay.
> >
> > On Sunday, September 17, 2023 at 5:02:35 AM UTC+8, Anton Shepelev wrote:
> >
> >>> I have recently bought Borland C++ 5.0 which was the last
> >>> version that supported a 16-bit target.
> >
> >> Does one still have to buy it?
> >
> > If you want to be squeaky clean, yes.
> >
> > I don't want 30 years of my life to be thrown away because
> > someone can accuse me of using pirated software to
> > develop PDOS.
> >
> > I heard (I don't know if it is true) that Microsoft paid some
> > schmuck to write a book claiming (lying) that Linus stole
> > code from Minix or something like that.
> >
> > Anyway, I've been buying heaps of stuff recently - mostly
> > Microsoft software. I have probably spend US$10k or
> > something on it. Most of it is showcased on my vlog at
> > http://pdos.org
> >
> > Pouring over license agreements too.
> >
> > Yesterday I spent all day trying to get Visual Studio 2003
> > to run on Windows 2000. I wanted to know if I could build
> > Hercules/380 and run it on Windows 95.
> >
> > Result is a bit complicated - but so far no, I need winsock2
> > I think.
> >
> >>> I have looked through the included documentation, and I
> >>> can't find any way to get the default pointer size/type to
> >>> be huge instead of far (as both Microsoft and Watcom do).
> >
> >> A peek into the User's guide shows they have no concept of a
> >> huge pointer, and only speak of huge and large /memory
> >> models/ and huge pointer /operations/. See the -mh, -mh,
> >> and -h switches:
> >
> > I don't know what you mean. The "huge" keyword exists and
> > generates the correct (desired) code.
> >
> > Anyway, here is the extra info requested:
> >
> > D:\scratch\zzz>type foo.c
> > char *foo(char *a)
> > {
> > return a + 5;
> > }
> >
> > D:\scratch\zzz>bcc -Od -S -mh foo.c
> > Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> > foo.c:
> >
> > D:\scratch\zzz>
> >
> > no change:
> >
> > ;
> > ; char *foo(char *a)
> > ;
> > push bp
> > mov bp,sp
> > ;
> > ; {
> > ; return a + 5;
> > ;
> > mov dx,word ptr [bp+8]
> > mov ax,word ptr [bp+6]
> > add ax,5
> > ;
> > ; }
> > ;
> > pop bp
> > ret
> >
> >
> >
> > D:\scratch\zzz>bcc -Od -c -mh foo.c
> > Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
> > foo.c:
> >
> > D:\scratch\zzz>
> >
> >
> > D:\scratch\zzz>dir /od
> > Volume in drive D has no label.
> > Volume Serial Number is 9C33-6BBD
> >
> > Directory of D:\scratch\zzz
> >
> > 2023-09-12 20:37 <DIR> ..
> > 2023-09-12 20:37 <DIR> .
> > 2023-09-14 11:48 76 fooadv.c
> > 2023-09-15 18:53 55 foo.huge
> > 2023-09-15 18:58 45 foo.c
> > 2023-09-18 03:11 1,060 foo.asm
> > 2023-09-18 03:12 199 foo.obj
> > 5 File(s) 1,435 bytes
> > 2 Dir(s) 7,364,018,176 bytes free
> >
> > D:\scratch\zzz>wdis foo.obj
> > Module: foo.c
> >
> > Segment: FOO_TEXT BYTE USE16 0000000E bytes
> > 0000 _foo:
> > 0000 55 push bp
> > 0001 8B EC mov bp,sp
> > 0003 8B 56 08 mov dx,word ptr 0x8[bp]
> > 0006 8B 46 06 mov ax,word ptr 0x6[bp]
> > 0009 05 05 00 add ax,0x0005
> > 000C 5D pop bp
> > 000D CB retf
> >
> > Routine Size: 14 bytes, Routine Base: FOO_TEXT + 0000
> >
> > No disassembly errors
> >
> > Segment: FOO_DATA WORD USE16 00000000 bytes
> >
> >
> > D:\scratch\zzz>
> >
> >
> >
> > D:\scratch\zzz>hexdump foo.obj
> > 000000 80070005 666F6F2E 639F8818 00000014 ....foo.c.......
> > 000010 54433836 20426F72 6C616E64 20432B2B TC86 Borland C++
> > 000020 20352E30 F9880500 00F90301 76880D00 5.0........v...
> > 000030 00E94697 2F570566 6F6F2E63 45880700 ..F./W.foo.cE...
> > 000040 00FA0000 00007788 030000E9 8C880500 ......w.........
> > 000050 00EA010D 7B962200 0008464F 4F5F5445 ....{."...FOO_TE
> > 000060 58540443 4F444508 464F4F5F 44415441 XT.CODE.FOO_DATA
> > 000070 08464152 5F444154 41DA9807 00280E00 .FAR_DATA....(..
> > 000080 02030125 98070048 00000405 010F900B ...%...H........
> > 000090 00000104 5F666F6F 000000BD A0120001 ...._foo........
> > 0000A0 0000558B EC8B5608 8B460605 05005DCB ..U...V..F....].
> > 0000B0 8F880E00 00E80105 666F6F2E 6346972F ........foo.cF./
> > 0000C0 57448A02 000074 WD....t
> >
> > D:\scratch\zzz>
> >
> >
> > BFN. Paul.
> >
> I admit I am surprised. It is evident that the compiler correctly
> interprets the memory model (-mh) in fact in the disassembled the
> function ends with the 'retf'. The only thing that comes to mind by
> observing the code of the function is that, in fact, it does not
> need to recalculate the address that it returns (e.g. 1234:0 -> 1234:5).
> Would you like to do a test for me again?
>
> char *foo(char *a)
> {
> return a + 65600;
> }
>
> In this way it should be obliged to recalculate. With the value 65600 I
> wanted to exaggerate because I think that 0x10 could be enough (greater
> than the less significant nibble of the offset).

D:\scratch\zzz>type foo.c
char *foo(char *a)
{ return a + 65600;
}

D:\scratch\zzz>

D:\scratch\zzz>bcc -mh -S -Od foo.c

; char *foo(char *a)
;
push bp
mov bp,sp
;
; {
; return a + 65600;
;
mov dx,word ptr [bp+8]
mov ax,word ptr [bp+6]
add ax,64
;
; }
;
pop bp
ret

D:\scratch\zzz>type foo.c
char *foo(char *a)
{ return a + 65600UL;
}

D:\scratch\zzz>

_foo proc far
?debug C E80105666F6F2E63BA833257
;
; char *foo(char *a)
;
push bp
mov bp,sp
;
; {
; return a + 65600UL;
;
mov dx,word ptr [bp+8]
mov ax,word ptr [bp+6]
add ax,64
;
; }
;
pop bp
ret
_foo endp

BFN. Paul.

Paul Edwards ha scritto:
> On Monday, September 18, 2023 at 4:33:31 AM UTC+8, jak wrote:
>> Paul Edwards ha scritto:
>>> Hi guys - thanks for your responses and sorry for the delay.
>>>
>>> On Sunday, September 17, 2023 at 5:02:35 AM UTC+8, Anton Shepelev wrote:
>>>
>>>>> I have recently bought Borland C++ 5.0 which was the last
>>>>> version that supported a 16-bit target.
>>>
>>>> Does one still have to buy it?
>>>
>>> If you want to be squeaky clean, yes.
>>>
>>> I don't want 30 years of my life to be thrown away because
>>> someone can accuse me of using pirated software to
>>> develop PDOS.
>>>
>>> I heard (I don't know if it is true) that Microsoft paid some
>>> schmuck to write a book claiming (lying) that Linus stole
>>> code from Minix or something like that.
>>>
>>> Anyway, I've been buying heaps of stuff recently - mostly
>>> Microsoft software. I have probably spend US$10k or
>>> something on it. Most of it is showcased on my vlog at
>>> http://pdos.org
>>>
>>> Pouring over license agreements too.
>>>
>>> Yesterday I spent all day trying to get Visual Studio 2003
>>> to run on Windows 2000. I wanted to know if I could build
>>> Hercules/380 and run it on Windows 95.
>>>
>>> Result is a bit complicated - but so far no, I need winsock2
>>> I think.
>>>
>>>>> I have looked through the included documentation, and I
>>>>> can't find any way to get the default pointer size/type to
>>>>> be huge instead of far (as both Microsoft and Watcom do).
>>>
>>>> A peek into the User's guide shows they have no concept of a
>>>> huge pointer, and only speak of huge and large /memory
>>>> models/ and huge pointer /operations/. See the -mh, -mh,
>>>> and -h switches:
>>>
>>> I don't know what you mean. The "huge" keyword exists and
>>> generates the correct (desired) code.
>>>
>>> Anyway, here is the extra info requested:
>>>
>>> D:\scratch\zzz>type foo.c
>>> char *foo(char *a)
>>> {
>>> return a + 5;
>>> }
>>>
>>> D:\scratch\zzz>bcc -Od -S -mh foo.c
>>> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
>>> foo.c:
>>>
>>> D:\scratch\zzz>
>>>
>>> no change:
>>>
>>> ;
>>> ; char *foo(char *a)
>>> ;
>>> push bp
>>> mov bp,sp
>>> ;
>>> ; {
>>> ; return a + 5;
>>> ;
>>> mov dx,word ptr [bp+8]
>>> mov ax,word ptr [bp+6]
>>> add ax,5
>>> ;
>>> ; }
>>> ;
>>> pop bp
>>> ret
>>>
>>>
>>>
>>> D:\scratch\zzz>bcc -Od -c -mh foo.c
>>> Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
>>> foo.c:
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> D:\scratch\zzz>dir /od
>>> Volume in drive D has no label.
>>> Volume Serial Number is 9C33-6BBD
>>>
>>> Directory of D:\scratch\zzz
>>>
>>> 2023-09-12 20:37 <DIR> ..
>>> 2023-09-12 20:37 <DIR> .
>>> 2023-09-14 11:48 76 fooadv.c
>>> 2023-09-15 18:53 55 foo.huge
>>> 2023-09-15 18:58 45 foo.c
>>> 2023-09-18 03:11 1,060 foo.asm
>>> 2023-09-18 03:12 199 foo.obj
>>> 5 File(s) 1,435 bytes
>>> 2 Dir(s) 7,364,018,176 bytes free
>>>
>>> D:\scratch\zzz>wdis foo.obj
>>> Module: foo.c
>>>
>>> Segment: FOO_TEXT BYTE USE16 0000000E bytes
>>> 0000 _foo:
>>> 0000 55 push bp
>>> 0001 8B EC mov bp,sp
>>> 0003 8B 56 08 mov dx,word ptr 0x8[bp]
>>> 0006 8B 46 06 mov ax,word ptr 0x6[bp]
>>> 0009 05 05 00 add ax,0x0005
>>> 000C 5D pop bp
>>> 000D CB retf
>>>
>>> Routine Size: 14 bytes, Routine Base: FOO_TEXT + 0000
>>>
>>> No disassembly errors
>>>
>>> Segment: FOO_DATA WORD USE16 00000000 bytes
>>>
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>>
>>> D:\scratch\zzz>hexdump foo.obj
>>> 000000 80070005 666F6F2E 639F8818 00000014 ....foo.c.......
>>> 000010 54433836 20426F72 6C616E64 20432B2B TC86 Borland C++
>>> 000020 20352E30 F9880500 00F90301 76880D00 5.0........v...
>>> 000030 00E94697 2F570566 6F6F2E63 45880700 ..F./W.foo.cE...
>>> 000040 00FA0000 00007788 030000E9 8C880500 ......w.........
>>> 000050 00EA010D 7B962200 0008464F 4F5F5445 ....{."...FOO_TE
>>> 000060 58540443 4F444508 464F4F5F 44415441 XT.CODE.FOO_DATA
>>> 000070 08464152 5F444154 41DA9807 00280E00 .FAR_DATA....(..
>>> 000080 02030125 98070048 00000405 010F900B ...%...H........
>>> 000090 00000104 5F666F6F 000000BD A0120001 ...._foo........
>>> 0000A0 0000558B EC8B5608 8B460605 05005DCB ..U...V..F....].
>>> 0000B0 8F880E00 00E80105 666F6F2E 6346972F ........foo.cF./
>>> 0000C0 57448A02 000074 WD....t
>>>
>>> D:\scratch\zzz>
>>>
>>>
>>> BFN. Paul.
>>>
>> I admit I am surprised. It is evident that the compiler correctly
>> interprets the memory model (-mh) in fact in the disassembled the
>> function ends with the 'retf'. The only thing that comes to mind by
>> observing the code of the function is that, in fact, it does not
>> need to recalculate the address that it returns (e.g. 1234:0 -> 1234:5).
>> Would you like to do a test for me again?
>>
>> char *foo(char *a)
>> {
>> return a + 65600;
>> }
>>
>> In this way it should be obliged to recalculate. With the value 65600 I
>> wanted to exaggerate because I think that 0x10 could be enough (greater
>> than the less significant nibble of the offset).
>
> D:\scratch\zzz>type foo.c
> char *foo(char *a)
> {
> return a + 65600;
> }
>
> D:\scratch\zzz>
>
>
> D:\scratch\zzz>bcc -mh -S -Od foo.c
>
>
> ; char *foo(char *a)
> ;
> push bp
> mov bp,sp
> ;
> ; {
> ; return a + 65600;
> ;
> mov dx,word ptr [bp+8]
> mov ax,word ptr [bp+6]
> add ax,64
> ;
> ; }
> ;
> pop bp
> ret
>
>
> D:\scratch\zzz>type foo.c
> char *foo(char *a)
> {
> return a + 65600UL;
> }
>
> D:\scratch\zzz>
>
> _foo proc far
> ?debug C E80105666F6F2E63BA833257
> ;
> ; char *foo(char *a)
> ;
> push bp
> mov bp,sp
> ;
> ; {
> ; return a + 65600UL;
> ;
> mov dx,word ptr [bp+8]
> mov ax,word ptr [bp+6]
> add ax,64
> ;
> ; }
> ;
> pop bp
> ret
> _foo endp
>
>
> BFN. Paul.
>

Well, I finished my ideas :-(
Just because I am stubborn and you could also be satisfied with a
aworkaround, I would make one last attempt to inform the compiler that I
would really like to use the Huge model mentioning it in the C source,
like:

void huge *huge_ptr = (void huge *)0L;

char *foo(char *a)
{ return a + 65600UL;
}

If not even this works I would try to ask my money back :-D

On Monday, September 18, 2023 at 11:47:04 PM UTC+8, jak wrote:

> Well, I finished my ideas :-(
> Just because I am stubborn and you could also be satisfied with a
> aworkaround, I would make one last attempt to inform the compiler that I
> would really like to use the Huge model mentioning it in the C source,
> like:
>
> void huge *huge_ptr = (void huge *)0L;
> char *foo(char *a)
> {
> return a + 65600UL;
> }
> If not even this works I would try to ask my money back :-D

Here is the result of that. And no, I don't need my money
back - I knew the limitations already for other versions.

https://ratman.biz/archive/young_ones/summerholiday.html

RICK: Yeah, c'mon. Robin Hood! Baader Meinhoff! Those bank clerks
didn't have to become bank clerks! They knew the risk when they took
the job! Let's go in and let them have it!

D:\scratch\zzz>type foo.c
void huge *huge_ptr = (void huge *)0L;

char *foo(char *a)
{ return a + 65600UL;
}

D:\scratch\zzz>bcc -mh -Od -S foo.c
Borland C++ 5.0 Copyright (c) 1987, 1996 Borland International
foo.c:

D:\scratch\zzz>

_huge_ptr label dword
db 0
db 0
db 0
db 0
FOO_DATA ends
FOO_TEXT segment byte public 'CODE'
assume cs:FOO_TEXT,ds:FOO_DATA
_foo proc far
?debug C E80105666F6F2E6361433457
;
; char *foo(char *a)
;
push bp
mov bp,sp
;
; {
; return a + 65600UL;
;
mov dx,word ptr [bp+8]
mov ax,word ptr [bp+6]
add ax,64
;
; }
;
pop bp
ret
_foo endp