Re: [Freedos-devel] Larger buffers in Watcom
Hello Mr. McMackins, hello Mr. Viste,
I found the bad code. While your example works, if I change it to use
calloc (which is what my code is using at the particular failure point),
then it fails. Looks like calloc is doing something funny.
Actually, I just found that both malloc( ) and calloc( ) do not work for
the purpose, and we _do_ need to use something like halloc( ).
I double-checked the compiler output (using `wdis test.o') for the
malloc( ) call under the huge model, and found that it actually clips
the size to a `size_t', and `size_t' is a 16-bit integer type even for
the huge model. I.e. malloc(81920) only allocates 16384 bytes.
#include
int main(void)
{
char __huge *buf = malloc(81920ul);
unsigned long i;
for (i = 0; i < 81920ul; ++i)
buf[i] = 0xf6; /* crash */
free(buf);
return 0;
}
halloc( ) however will correctly allocate a buffer that spans multiple
segments.
Thank you!
--
https://github.com/tkchia
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Larger buffers in Watcom
I found the bad code. While your example works, if I change it to use
calloc (which is what my code is using at the particular failure point),
then it fails. Looks like calloc is doing something funny.
Happy Hacking,
David E. McMackins II
Supporting Member, Electronic Frontier Foundation (#2296972)
Associate Member, Free Software Foundation (#12889)
www.mcmackins.org www.delwink.com
www.eff.org www.gnu.org www.fsf.org
On 07/28/2018 12:31 PM, Mateusz Viste wrote:
> On Sat, 28 Jul 2018 11:49:42 -0500, David McMackins wrote:
>> Is there a way to allocate a buffer in OpenWatcom that is larger than
>> 64k?
>
> Sure. Either use XMS/EMS, or rely on the "huge model" kludge.
>
>> I'm currently trying to stay within the compact memory model, but
>> even if I compile for huge memory model, I'm getting an out of memory
>> error for trying to allocate about 80k for a buffer.
>
> Either your code is bad or you truly do not have any available block of
> 80K contiguous conventional RAM.
>
> I tested it right now with the code below, and it works as expected
> (prints "success!"):
>
> /* compile: wcl -0 -mh -os -lr test.c */
> #include
> #include
>
> int main(void) {
> char *buf;
> buf = malloc(81920l);
> if (buf == NULL) {
> printf("oops\n");
> } else {
> buf[8l] = '!';
> buf[80001l] = 0;
> printf("success%s\n", buf + 8l);
> free(buf);
> }
> return(0);
> }
>
>> My machine has 128M
>> of memory, so I'm not actually running out of memory.
>
> That is irrelevant, since we are talking conventional memory here.
>
>> This code works
>> fine under DJGPP, so I know my hardware is capable.
>
> Apples and oranges. DJGPP is protected mode, while you are using real
> mode.
>
> Mateusz
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Larger buffers in Watcom
On Sat, 28 Jul 2018 11:49:42 -0500, David McMackins wrote:
> Is there a way to allocate a buffer in OpenWatcom that is larger than
> 64k?
Sure. Either use XMS/EMS, or rely on the "huge model" kludge.
> I'm currently trying to stay within the compact memory model, but
> even if I compile for huge memory model, I'm getting an out of memory
> error for trying to allocate about 80k for a buffer.
Either your code is bad or you truly do not have any available block of
80K contiguous conventional RAM.
I tested it right now with the code below, and it works as expected
(prints "success!"):
/* compile: wcl -0 -mh -os -lr test.c */
#include
#include
int main(void) {
char *buf;
buf = malloc(81920l);
if (buf == NULL) {
printf("oops\n");
} else {
buf[8l] = '!';
buf[80001l] = 0;
printf("success%s\n", buf + 8l);
free(buf);
}
return(0);
}
> My machine has 128M
> of memory, so I'm not actually running out of memory.
That is irrelevant, since we are talking conventional memory here.
> This code works
> fine under DJGPP, so I know my hardware is capable.
Apples and oranges. DJGPP is protected mode, while you are using real
mode.
Mateusz
--
FreeDOS is present on the USENET, too! alt.os.free-dos
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Larger buffers in Watcom
Hello Mr. McMackins,
Is there a way to allocate a buffer in OpenWatcom that is larger than
64k? I'm currently trying to stay within the compact memory model, but
even if I compile for huge memory model, I'm getting an out of memory
error for trying to allocate about 80k for a buffer. My machine has 128M
of memory, so I'm not actually running out of memory. This code works
fine under DJGPP, so I know my hardware is capable.
I think the hmalloc( ) and hfree( ) functions in should do
the job, even in a small-model program:
#include
int main(void)
{
char __huge *buf = halloc(80, 1024);
unsigned long i;
for (i = 0; i < 80ul * 1024; ++i)
buf[i] = 0xf6;
hfree(buf);
return 0;
}
The __huge buffer will be limited to the lower 1 MiB or so of
conventional memory though.
Thank you!
--
https://github.com/tkchia
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Fwd: Larger buffers in Watcom
Perhaps I should clarify that by "buffer" I just mean some space on the heap allocated via malloc() Forwarded Message Subject: Re: [Freedos-devel] Larger buffers in Watcom Date: Sat, 28 Jul 2018 18:55:31 +0200 From: Eric Auer To: David McMackins Hi David, maybe there is a misunderstanding in the meaning of buffer between you (general memory allocation) and the compiler (maybe uses buffers for something specific only, eg DMA)? Or you selected a memory model with real mode pointers or pointers with 16 bit offsets? Probably you can nevertheless allocate multiple memory blocks of max 63.99k each? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] Larger buffers in Watcom
Is there a way to allocate a buffer in OpenWatcom that is larger than 64k? I'm currently trying to stay within the compact memory model, but even if I compile for huge memory model, I'm getting an out of memory error for trying to allocate about 80k for a buffer. My machine has 128M of memory, so I'm not actually running out of memory. This code works fine under DJGPP, so I know my hardware is capable. Happy Hacking, David E. McMackins II Supporting Member, Electronic Frontier Foundation (#2296972) Associate Member, Free Software Foundation (#12889) www.mcmackins.org www.delwink.com www.eff.org www.gnu.org www.fsf.org -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] gcc-ia16 packaging (was: Re: Starting FreeDOS 1.3)
Hello Rugxulo, hello Mr. Mateusz Viste, Actually, you should be able to use LZMA compression in the main .ZIP itself to squeeze some more space. I don't recall if any other packages used that (yet). I think Mateusz was vaguely worried about wasting dozens of MB of RAM just to unpack. Using LZMA for the gcc package would totally make sense, yes. This is the kind of situations I was thinking about when I implemented LZMA inside FDNPKG few years ago. The problem with LZMA is that it requires tremendous amounts of memory to unpack (24 MB at least according to my tests), hence it clearly won't run on a 8086. Knowing that gcc itself requires at least a 386+ and many megabytes of memory, I don't see any problem in making the gcc package non-installable on systems that wouldn't be able to run it in the first place anyway. Thank you! I have uploaded an updated package set at https://github.com/tkchia/build-ia16/releases/tag/20180728-redist-djgpp . I think for now I will include just the source patches for Binutils and GCC --- but I will include the full sources for those too, if Mr. Hall needs/wants me to. (I figure that one should have little problem anyway in getting the official Binutils and GCC sources, which are mirrored in several places.) I also hope to clarify the licensing status of the build-ia16 scripts (which I forked from https://github.com/crtc-demos/build-ia16), to see if they can be mirrored in the future. I have found that using LZMA does allow me to shave at least a few hundred KiB off each package, which is always useful. :) My only peeve for now is that 7-Zip does not have something like Info-Zip's -k/--DOS-names option --- I would want to be able to use LZMA _and_ convert file names to 8 + 3 format, at the same time. Thank you! -- https://github.com/tkchia -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
