#Memory Use
21 messages in this thread
I'm working on a programming article for AmigaWorld, about allocating memory in
C. Does anyone know the size of the memory blocks used in Lattice's sbrk()
function? This is the Level 1 memory allocation function that gets memory from
AmigaDOS, for management by the malloc() and free() calls. I know Manx's
heapsize is 40K, and they have a _Heapsize long that you can set to adjust it.
Does Lattice have a similar facility? Does Lattice sell the source code to
their libraries? Having Manx's code was very useful for understanding these
functions. Lattice's 4.0 manual does describe sbrk() and rbrk(), but it
doesn't tell the size of the heap.
Second, if I had a system with three autoconfig 2 meg boards, I wouldn't be
able to AllocMem() a contiguous 3 meg hunk, until I ran the MergeMem utility?
In other words, AmigaDOS does not merge memory boards together.
The sbrk() routine allocates the amount of memory specified. It does not
acquire a larger heap. If you want to use standard heap sizes, you must use
the higher level functions such as malloc(). You may be interested in looking
under _MNEED and _MSTEP in the library documentation for setting the standard
heapsize etc.
Lattice will sell library source. You should call our sales department and ask
for details on how to purchase it. I believe you need to sign a non-disclosure
agreement to purchase it.
BTW, you should be looking in the 5.0 documentation for the memory info. I will
also mention that future versions of the libraries will not necessarily work
the same way as 5.0. I have been redesigning much of the code to improve
performance and functionality.
Thanks for the tips. sbrk()'s manual page didn't mention the _MNEED and
_MSTEP, so that's why I asked here. I only have 4.0.
I'd recommend getting 5.04. It really is worth it. 🙂 If you have any more
questions, just ask!
— Mike Roth
Actually, we do have 5.04 for one of my partners at my company, but that's in
the office, and I don't use it here. All I have to do is find my upgrade card,
right? 🙂 I'd love to switch to Lattice for our production code, but I'd
have to port a meg or two of source code from Manx 3.6a. Porting and testing
would take *months*.
I'd be quite surprises if it really took months to port software from Manx to
Lattice. Many of the warnings we generate for sloppy code can be ignored,
anyway. 🙂 You might want to ask others who have switched how easy it was to
port code over.
— Mike Roth
I've DEVELOPED code that works with IBM-PC Manx and Amiga Lattice. The only
#define switches I needed were to handle differences between the Amiga and
MS-DOS, not differences between Manx and Lattice. Of course, I wasn't trying
to manipulate existing code, but the differences SHOULD be small.
– Don Nafis – Nazlo Associates Ltd –
Mike,
I ported a (roughly) 1000 line Manx program to Lattice. It took me about 4
hours. I got it running in about 30 minutes — the other 3.5 hours was to get
it to compile without warnings (I _hate_ warnings!).
-sja
You might consider waiting for Manx 5.0 to come out before deciding to switch.
Code generation in 5.0 is very much improved over the 3.6a release, which seems
to be the major factor you're interested in. In addition, 5.0 compiles about
25% faster than 3.6a does (that translates into about 15-quadrillion times
faster compilation than Lattice). These are not official benchmark figures, of
course.
-Mike
Are you beta testing Manx 5.0, or do you work for Manx? Or both? 🙂 Any
notion of when it will be released?
I am an employee of Manx Software Systems. I do several things at Manx, among
them over-seeing the logistic details of the 5.0 beta and release products (Jim
Goodnow is the head-programmer for our Amiga projects).
5.0 should be available this month. I can't give an exact time, though, as we
are at the mercy of our printers at this point (we're waiting for them to
finish the new 5.0 documentation). When it is officially available, I'll post
a message here.
-Mike
Are we going to get a new set of docs with 5.0, or a bunch of
"addendum" pages will have to be inserted all over the old docs???? I hope
since we're dealing with a major update, we can lose the old docs and
replace it with a fresh clean new slate! They offered this with the latest
Lint!
Everyone who orders the 5.0 upgrade (or buys it new, for that matter) will
get completely re-written documentation. So yes, you can throw your 2.3
million pages of release documents away 😎
You should know that there are two different forms of memory allocation in
Aztec. One type uses a limited heap (_Heapsize I suppose), in this case the
heap is set at the beginning and will NOT grow. If you want to use this
memory manager you have to link with heapmem.o. The other heap manager will
allocate blocks from the OS as needed in uniform blocks and release them at
program termination ( I think ), which is the default for of memory
managment.
Your second question, I think that boards may not allow memory to be
contiguous. I think MergeMem only works if there actually is contiguous
memory, which may NOT be the case if the boards were not set up correctly.
MergeMem may not work if thare any non-free blocks of memory at the
boundries of the address space of two adjecent (in address) boards. -BOB-
I'm not quite sure I understood what you said. Aztec has two memory
managers? I looked at 'heapmem.o', and it only shows one manager. Where is
the other one? I didn't see it in the docs, either. The one in 'heapmem.c'
allocates a big block. I wonder what happens if you set _Heapsize to
something very small? Meanwhile, the article is already gone, so this is a
moot point, for the purposes of the article. For me, I'm interested. 🙂
The default memory manager is part of c.lib, where as the alternative manager
is contained in heapmem.o, as has already been mentioned. The difference
between them is that the default manager really isn't a manager – it just calls
AllocMem(). In fact, the default manager doesn't even have a realloc()
routine! The advantage of the default manager is that you can allocate as much
as you want (w/in memory constraints, of course). The manager in heapmem.o, on
the other hand, only has _Heapsize bytes to work with. This manager is must
faster than the default, however, and also includes a realloc() routine.
I hope this clears up the confusion.
-Mike
Can you tell me where this is documented? I couldn't find it anywhere. The
manager must at least keep a list of the malloc()s, of course, or the automatic
free on exit wouldn't happen. Or is that what happens? As I interpreted
heapmem.c, it takes at least _Heapsize bytes for each block of memory. If you
ask for more, it makes a bigger block. Again, I saw no mention of the kinds of
manager you're talking about, in the Manx manual.
Unfortunately, neither heap manager is adequately documented in v3.6a – in
fact, heapmem.o isn't in the manual at all. Version 5.0 will have only one
method of heap allocation which will be a combination of the two existing
methods.
Oh, you're right – I believe heapmem.o does work more like a 'normal' malloc,
in that _Heapsize really is just the block-size requested from the operating
system, which is cut into smaller-chunks (if necessary) for the user. If you
request more than _Heapsize bytes, then malloc will ask for as many blocks of
size _Heapsize which will satisfy the request.
-Mike
You had me scared there for a minute. I'd submitted my article last week,
based on the idea that the regular malloc() in 3.6a is managed by the
source code I saw in heapmem.c. As for this other method you mentioned,
that is, the "other" malloc() that just uses AllocMem()… is that some
new heap manager in 5.0, or what?
Glad to see someone from Manx online. I thought Goodnow was taking quite a
sabbatical, if he'd been invisible this long. Is 5.0 the same as was
promised a year ago, or have new features crept in since then?
The default heap manager in c.lib uses AllocMem, NOT the _Heapsize stuff in
heapmem.c. Version 5.0 will have a hybrid-system which uses AllocMem but also
allows realloc'ing. Sorry if I didn't make that clear 😎
Jim has been doing programming work at Manx all along – he just dropped out of
the lime-light, as it were. My work regarding the Amiga is primarily light to
medium programming work, as well interacting w/ users (beta users, BIXen, CIS
users, as well as people who call).
I'll put a feature list together sometime soon that I can upload here which
details everything that's in 5.0.
-Mike
The default memory manager DOES release memory upon exit.
-Mike