visual studio 1.52 huge memory model

[muta...@gmail.com]

Hi.

We have previously discussed laying out the PM16
selectors. And I remember we agreed that the code
selectors and data selectors needed to be
intermingled to provide a somewhat flat (ie not
really flat, more consecutive) address space.

Anyway, I recently purchased Visual Studio 1.52
from ebay and it runs under Windows and produces
real memory code, and the huge memory model is
pretty good, and in fact, I think Microsoft C 5.1
generated the same/similar code.

However, I'm not sure whether this is sufficient to
do PM16 the way I want.

Apparently it IS sufficient to do PM16. There is a
AHSHIFT and an AHINCR (not generated in this
case). But just because it works for PM16 the way
Windows does it, doesn't mean it will work for the
way I want to do PDOS/286.

Note that Watcom is completely flexible - it calls an
external function to manipulate huge pointers.

So my question is - is the Visual Studio-generated code
sufficient for a somewhat-flat address space that we
previously discussed? It's flat from the perspective of
the C programmer, who has access to 16 MiB on an
80286 and access to (what did we say? 256 MiB I
think - on PM16 on an 80386 - and 512 MiB on PM32
with D-bits set to 16-bit, maybe?).

Thanks. Paul.



D:\scratch\xxx>type foo.c
char *foo(char *in, long x)
{
return (in + x);
}

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

foo.c

D:\scratch\xxx>type foo.asm
; File foo.c
; Line 2
; in = 0006
; x = 000a
_foo:
push bp
mov bp,sp
mov ax,OFFSET L00106
call FAR PTR __aFchkstk
push si
push di
; Line 3
mov ax,WORD PTR 10[bp]
mov dx,WORD PTR 12[bp]
mov cx,WORD PTR 6[bp]
mov bx,WORD PTR 8[bp]
add ax,cx
adc dx,OFFSET 0
mov cx,OFFSET __AHSHIFT
shl dx,cx
add dx,bx
jmp L00105
; Line 4
; Line 4
L00105:
pop di
pop si
mov sp,bp
pop bp
ret OFFSET 0

D:\scratch\xxx>

[muta...@gmail.com]

On Tuesday, June 6, 2023 at 5:47:34 PM UTC+8, muta...@gmail.com wrote:

> We have previously discussed laying out the PM16
> selectors. And I remember we agreed that the code
> selectors and data selectors needed to be
> intermingled to provide a somewhat flat (ie not
> really flat, more consecutive) address space.

Here is one of the discussions:

https://groups.google.com/g/alt.os.development/c/0f3Ns-Q_R4M/m/J_1X9yflAAAJ

where I said that I needed two values - a divide value
(of the amount being added) and a multiply (of how
to manipulate the segment), but that both of these
could potentially be shifts instead.

Plus I found this, not sure if it is related:

http://www.delphigroups.info/2/ae/107069.html

{ AHincr is 8 in Standard and Enhanced mode, $1000 in real mode.
AHshift is 3 in Standard and Enhanced mode, 12 in real mode (2^AHshift=AHincr) }


Regardless, it sounds to me like Microsoft found another
way to skin the cat, presumably superior to my design, and
that's what their compiler is generating (as opposed to
Watcom's flexible design where I could have implemented
my own manipulation), so there's no particular reason why
I wouldn't just copy Microsoft on this.

And since this code works on PM16 apparently, it may mean
there is an existing call (Windows 3.1 or OS/2 1.0?) to get
the AHINCR and AHSHIFT values.

And it looks to me like that AHSHIFT of 3 was designed to
manipulate selectors that contain consecutive data. I believe
we previously said that my design required intermingled
cs + ds, so the data selectors will be 0x10 apart, presumably
meaning AHSHIFT of 4 instead of 3.

Any idea if there are MSDOS or Windows or OS/2 calls to
retrieve these 2 values?

Thanks. Paul.

[Alexei A. Frounze]

https://retrocomputing.stackexchange.com/questions/21559/

Alex

[Alexei A. Frounze]

https://forum.vcfed.org/index.php?threads/segment-descriptor-behavior-in-non-flat-protected-mode-c-compilers.45331/

Alex

[muta...@gmail.com]

On Sunday, June 18, 2023 at 7:32:51 AM UTC+8, Alexei A. Frounze wrote:

> https://retrocomputing.stackexchange.com/questions/21559/

That's fantastic, thanks. And the API I need is:

http://www.edm2.com/index.php/DosGetHugeShift

which is a "family API", which I believe means that it will run
on MSDOS, which means that there is probably an interrupt
that is ultimately called. Or perhaps they just hardcoded the
required values when detecting that it was an MSDOS
environment rather than OS/2 1.0 (I wonder what they did
to detect the environment?).

I never used "family API", but I think that's what I need to
do now. And perhaps add PDOS to the "family"? Given that
I have quite a number of extensions.

BFN. Paul.

[muta...@gmail.com]

On Sunday, June 18, 2023 at 5:20:59 AM UTC+8, muta...@gmail.com wrote:

> where I said that I needed two values - a divide value
> (of the amount being added) and a multiply (of how
> to manipulate the segment), but that both of these
> could potentially be shifts instead.

Actually, it's unclear to me why I thought I needed two
values, and indeed, Microsoft has two as well (but I've
only seen one used).

It seems to me that I just need that one value returned
by DosGetHugeShift.

BFN. Paul.

[Dan Cross]

In article <1510422c-202a-4b42...@googlegroups.com>,

Alexei A. Frounze <alexf...@gmail.com> wrote:
>On Saturday, June 17, 2023 at 2:20:59 PM UTC-7, muta...@gmail.com wrote:

>>[snip]
>> Thanks. Paul.
>
>https://retrocomputing.stackexchange.com/questions/21559/

Please don't feed the troll.

- Dan C.

[muta...@gmail.com]

I think it is because the selectors are not necessarily
spaced 64k apart. They may only be 8k apart for example,
for better granularity. It would change depending on how
much memory is available (and designed to max out the
available selectors).

Therefore I would be dividing the offset by 8 to find out how
many selectors I need to advance.

Although this would only be relevant if I needed the pointers
normalized, which Visual C++ doesn't appear to be doing.

BFN. Paul.