16 bit integers in 11.0c?

[Byron Blue]

Is there any way to force Watcom to use two bytes for integers instead of
four? Large arrays consume a lot of needless memory.

Byron Blue

[Byron Blue]

I changed the two arrays in question to short (two bytes) instead of int
(four bytes) and gained 16.77 Mb. The data seems fine.
Are there any issues which we surface if I start changing ints to shorts
across the board?

"Byron Blue" wrote in message news:l0kl7e$7n9$***@www.openwatcom.org...

Is there any way to force Watcom to use two bytes for integers instead of
four? Large arrays consume a lot of needless memory.

Byron Blue

[Paul S. Person]

On Mon, 9 Sep 2013 10:32:31 -0400, "Byron Blue"

Post by Byron Blue
I changed the two arrays in question to short (two bytes) instead of int
(four bytes) and gained 16.77 Mb. The data seems fine.
Are there any issues which we surface if I start changing ints to shorts
across the board?

Anything that involves converting a 4-byte int to a 2-byte int is
going to require a cast. Well, depending on the error level you have
selected, I suppose.

Converting everything should pretty much avoid that, of course, except
for library functions that return a 4-byte int which you stuff into a
2-byte int.

[Peter C. Chapin]

Post by Byron Blue
I changed the two arrays in question to short (two bytes) instead of int
(four bytes) and gained 16.77 Mb. The data seems fine. Are there any
issues which we surface if I start changing ints to shorts across the
board?

I'm not sure what issues you are wondering about. Are you worried about
portability between compilers? Are you worried about overflow? Are you
worried about errors when calling library functions?

Peter

[Byron Blue]

Thanks all
The issue is that I've found the system running out of RAM.
The application is a 32 bit DOS based sonar processor and passes large
amounts of data.
The hardware is Intel with 2GB of RAM (which of course should be
substantial).
When I use MGL_availableMemory() to query the free memory it returns a low
value (< 40MB).
I've looked over the code and made some changes to improve the RAM profile
but am now suspicious that the setup of Watcom/PMODEW is configured to only
use 64MB of RAM. I've ran the PMWSETUP utility but it seems to be set up
fine. At a bit of a loss at the moment...
Byron

Post by Byron Blue
I changed the two arrays in question to short (two bytes) instead of int
(four bytes) and gained 16.77 Mb. The data seems fine. Are there any
issues which we surface if I start changing ints to shorts across the
board?

I'm not sure what issues you are wondering about. Are you worried about
portability between compilers? Are you worried about overflow? Are you
worried about errors when calling library functions?

Peter

[Paul S. Person]

On Tue, 10 Sep 2013 07:44:50 -0400, "Byron Blue"

Post by Byron Blue
Thanks all
The issue is that I've found the system running out of RAM.
The application is a 32 bit DOS based sonar processor and passes large
amounts of data.
The hardware is Intel with 2GB of RAM (which of course should be
substantial).
When I use MGL_availableMemory() to query the free memory it returns a low
value (< 40MB).
I've looked over the code and made some changes to improve the RAM profile
but am now suspicious that the setup of Watcom/PMODEW is configured to only
use 64MB of RAM. I've ran the PMWSETUP utility but it seems to be set up
fine. At a bit of a loss at the moment...

Speaking theoretically, it should be possible, by allocating known
memory blocks, to see what the limits really are.

At least then you would know what you are up against.

[Byron Blue]

The system is running under DOS 6.22.
I tried just now using the DOS/32 Advanced DOS Extender. The numbers I read
come up the same as with PMODE.
I'm using MGL_availableMemory() to query the status.
Could it be either Watcom or DOS 6.22 setting the limit?
Byron

"Paul S. Person" wrote in message news:***@4ax.com...

On Tue, 10 Sep 2013 07:44:50 -0400, "Byron Blue"

Post by Byron Blue
Thanks all
The issue is that I've found the system running out of RAM.
The application is a 32 bit DOS based sonar processor and passes large
amounts of data.
The hardware is Intel with 2GB of RAM (which of course should be
substantial).
When I use MGL_availableMemory() to query the free memory it returns a low
value (< 40MB).
I've looked over the code and made some changes to improve the RAM profile
but am now suspicious that the setup of Watcom/PMODEW is configured to only
use 64MB of RAM. I've ran the PMWSETUP utility but it seems to be set up
fine. At a bit of a loss at the moment...

Speaking theoretically, it should be possible, by allocating known
memory blocks, to see what the limits really are.

At least then you would know what you are up against.

[Johann Klammer]

Post by Byron Blue
The system is running under DOS 6.22.
I tried just now using the DOS/32 Advanced DOS Extender. The numbers I
read come up the same as with PMODE.
I'm using MGL_availableMemory() to query the status.
Could it be either Watcom or DOS 6.22 setting the limit?
Byron

The causeway source mentions VCPI XMS INT15 Conventional and RAW
memory.. see:
http://perforce.openwatcom.org:4000/@md=d&cd=//depot/openwatcom/contrib/extender/causeway/source/all/&cdf=//depot/openwatcom/contrib/extender/causeway/source/all/raw_vcpi.asm&c=UhY@//depot/openwatcom/contrib/extender/causeway/source/all/raw_vcpi.asm?ac=64&rev1=1

in PhysicalGetPage function and other places

perhaps try loading none of the memory management drivers(XMS.. EMM386)
and see if things change...

[Wilton Helm]

There is an unfortunate expression rule in C that may byte you here. It
states that anything smaller than int gets promoted to int in an expression.
The intent of the rule was that traditionally CPUs had only one size of data
that they operated on most efficiently--the width of the register. Making
that the "common denominator" would generate the most efficient code.
However when you use a processor like an x86 that can work with equal
efficiency on 8, 16 or 32 bit data, that little rule becomes a real
nuisance.

Often you won't notice the difference, but if you are doing things that
involve bit manipulation or bit masking and comparision, and you happen to
be using signed versions of things, the promotion will put a bunch of 1s in
the upper bits if the value had the MSB set, which is not anticipated.
Masking them out before testing works. It may generate extra code, or the
optimization may recognize the uselessness of the extra bits and optimize
them away.

A related issue is that the promotion to int takes at least one extra
instruction every time it occurs. Again, masking may clue the optimizer
into eliminating this, but at the expense of messy looking code.

Similar stuff happens when using char for numerical puposes. Again a
situation where at least on x86 the promotion rule is rather short sighted.
I can't think of a case where simply promoting to the largest size in the
expression wouldn't have generated equally correct code that often is more
compact and faster.

In fact I feel strongly enough about it that I think there should be a
compile switch that overrides the behavior. I'd leave it on all the time.
Again, I can't think of a single case where it would produce adverse
effects.

Wilton