#Workbench hints and tips
15 messages in this thread
But may also load the ARP.LIBRARY to run, and thereby exceed the total
amount of ram used by 17k of "std" cmds. Just a thought.
ArpLib V1.3 is about 17K, so combined with the sample group of commands the
total is about 27K, compared with about 30K for the BCPL commands. If
you'd care to compare any other actual figures, I'll be glad to provide the
ARP figures.
My point was the following… arplib in ram, arp cmds in ram – 27k (or so,
I'll take yer wrd) run an arp cmd, arp lib gets loaded, so does cmd – total
in ram is now 27k + 17k for arp lib + cmd (1k?) Worse off than the CBM
cmds. Now, if you don't pout arp lib in ram, then you save – sorta…
however, every time arp lib gets unloaded, (low memory) you have to go back
to floppy. Right?
Why would you have arplib in ram? The total ram was 27K .vs. 30K,
including arp.library, if you use only the 6 commands mentioned. If you use
all 55 or so ARP commands, you'll wind up with about 70K bytes more free
disk space just by copying the files over the C= V1.3 versions. If you use
a shell that recognizes the ARP header and you've set "Stack 20000", you'll
save 16,000 bytes of stack each time an ARP command is run. If you have
other programs which use arp.library, the shared code becomes even more
efficient. Just out of curiosity, Ben, have you ever run on a system with
the ARP commands?
Last question first – not since the very first release. arp is a lib,
right? if a cmd uses a resource in it, it has to be loaded in ram, right?
or am I lost?
Yes, arp.library is a library. Your math was counting the size of
arp.library twice; it only needs to be loaded once.
It's in the ram disk; that's ONE. It's loaded when a program needs it;
that's two. If it's NOT in the ram disk, then you don't have the same
advantage as the CBM commands, which can be run with no extra overhead,
even under heavy memory loads. Since we're talking about size.
Since arp.library may be UNLOADED by virtually any low memory "happening",
either you have it in the ramdisk so it can be reloaded fast, or you have
it on floppy, whereby you lose the "cmds in ramdisk" advantage to some
extent, depending on the environment. Yes? No?
No, in a simple answer. It's easy to keep arplib loaded, if you want to.
Try using it, then report back, Ben.
Ok – if it's easy to keep it loaded, then ARP commands have a 17k overhead
all the time that CBM commands don't. One way or another, it's not the same
thing. I will try ARP – this weekend. I want to make an ARexx script that
uses your file requester in Board Master. Given the number of people who
like that thing, and the ease it can be done (unless it's difficult to
invoke, which I presume is NOT the case) I might as well throw that in
there, too. While I'm at it, I'll give the commands a whirl. I guess if I
want to butt heads with you I do need more info about now.
It's always best to know what you are talking about before you argue with
someone Ben. <grin> -msl-
Ben – you might want to wait a week before you give ARP another look; V1.3
should be out next Friday, barring major problems in the final round of
beta testing. We've made a lot of enhancementes in V1.3, so it's probably
worth waiting since it's so close now-
butting in… don't forget that the cbm commands from echo to dir *start*
by allocating enough memory to copy the global vector table for
themselves. That's not 17k, but it's memory fragging and grabbing that
doesn't need to be happen'n. butting out…
Heck – I didn't forgget – I din't *know*. I'll be playing with ARP this
weekend. Give me a few days after that – then we'll see.
Scott,
I'd like to know more about how that works – the copying of the global vector
table, and how it fragments memory. Is that in the RKM? Where can I read
about it?
Betty
You can't read about it, it happens in the bcpl startup code which is at
the beginning of all the bcpl startup programs. I discovered it by
examining the startup code. It doesn't fragment memory any more than any
other middling allocation, my point was that it is not needed. Without
looking at my disassembly, it goes something like this:
The startup code finds the highest global vector it needs from the tail end
of it's bcpl segments, and allocates enough memory for that. The gvtable
has a 'negative' portion, which corresponds to the dos.library callouts for
the most part, and a positive portion.
This is used partially to store startup segments entry points from the
program, and partly to store global data (the cli structure is copied to
the private vector, for example), and the rest are entrypoints into the
private dos stuff. There are calls in this private dos stuff to copy
vectors to the new table.
I learned about it when I made the arp process stuff support bcpl programs,
can't imagine why any one else would want to know it.