VOGONS

anyone knows about lattice c?

Topic actions

First post, by noshutdown

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

to try out how this compiler of 1982 performs, i wrote a very simple program just to display how much ram is available for malloc:

#include <stdio.h>
int main()
{
int result=0;
long freeram=0;
result=allmem();
if (!result)
{
freeram=sizmem();
freeram*=sizeof(int);
printf("%ld bytes free.\n", freeram);
}
else
{
printf("expanding memory pool failed!\n");
}
return 0;
}

it compiled and linked, but says that i have only 18 bytes of ram available. whats wrong with it?

Reply 1 of 5, by BloodyCactus

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

I have a couple of version of lattice c installed. Its not using DOS to get free mem, its using its internal memory model and heap. It grows this as neededd using SBRK.

Therefore, the value returned by "sizmem" does not necessarily indicate how much memory is actually available. If used after calling "allmem", however, the actual memory pool size WILL be returned.

Lattice C MEMORY POOL, is not dos's free memory size.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 2 of 5, by noshutdown

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie
BloodyCactus wrote on 2020-02-18, 03:14:

I have a couple of version of lattice c installed. Its not using DOS to get free mem, its using its internal memory model and heap. It grows this as neededd using SBRK.

Therefore, the value returned by "sizmem" does not necessarily indicate how much memory is actually available. If used after calling "allmem", however, the actual memory pool size WILL be returned.

Lattice C MEMORY POOL, is not dos's free memory size.

what i want to display is the size of ram that i can allocate for data,
as you can see i already called allmem().
i then found that you need to declare

long sizmem();

, weird by today's standard.
it then displays that the memory pool is 1261568bytes, this is again ridiculous as it easily breaks the 640kb barrier and is even over 1mb for computers of 1982.
then i looked up manual again, and found that in lc2.0 sizmem() returns size of memory pool in unit of bytes instead of ints, so it shall be right if i remove "freeram*=sizeof(int)".

as for old compilers(not the new ones like turboc), do you have any ideas to recommend?

Reply 3 of 5, by BloodyCactus

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

for old compilers, there is also power c, I have a soft spot for power c and old turbo c 1.0

Its kinda funky you can still buy power-c today
http://www.mixsoftware.com/product/powerc.htm

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 4 of 5, by noshutdown

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

there is one more question:
since allmem() allocates all available memory into the memory pool(which ought to be in the heap), does that mean there would be no memory left for the stack and i can't perform any recursive function calls?

Reply 5 of 5, by BloodyCactus

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

stack is not part of the heap, its usually fixed by the EXE header. c compilers on dos dont grow stack, stack is a fixed size on link time usually. recurse too much and you will just crash.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Go to top of page Go to top of page
Back to Software
Close window
Close window