adam@lamont.Columbia.edu (adam levin) (03/26/88)
I have a 'C' array which needs to be in chip RAM. The examples I have found
declare the array, AllocMem some chip RAM, and copy the array into it.
This is wasteful if all one has is chip RAM, or if the program was linked
with Manx's +C option. I wrote the following routine, and I'd like to know
if this is a reasonable way to avoid the unnecessary copy. Must I #include
the value of FAST_STARTS, or is it available in some system structure?
/* MemType - Given a starting address and a length, returns
either MEMF_CHIP, MEMF_FAST, or both.
25-Mar-1988 aklevin
*/
#include <exec/types.h>
#include <exec/memory.h>
#define FAST_STARTS 0x80000L
ULONG
MemType(start, length)
ULONG start, length;
{
if (start >= FAST_STARTS) return(MEMF_FAST);
if (start + length < FAST_STARTS) return (MEMF_CHIP);
else return (MEMF_FAST | MEMF_CHIP);
} /* end MemType() */
/* Here is a code fragment to show how I use MemType(): */
int i;
USHORT *varipointer, pointer[] = { 0x0000, 0x0c80,... 0x0202 };
if (MemType((ULONG)pointer, (ULONG)sizeof(pointer)) == MEMF_CHIP)
/* If it is already in chip RAM, use the existing pointer. */
varipointer = pointer;
else {
/* Otherwise, attempt to allocate chip RAM for it. */
varipointer = (USHORT *)AllocMem((long)sizeof(pointer), MEMF_CHIP|MEMF_CLEAR);
/* If chip RAM was successfully allocated, copy the array into it. */
if (varipointer) {
for(i=0; i<sizeof(pointer)/sizeof(USHORT); i++)
varipointer[i] = pointer[i];
} /* end if */
/* Otherwise exit (I made up the NO_CHIP_RAM constant). */
else exit(NO_CHIP_RAM);
} /* end else */
/* From here on I use varipointer to access the array. */
/* To deallocate the memory: */
/* If the varipointer exists, and is not the same as pointer,
it was allocated, so deallocate. */
if (varipointer && varipointer != pointer)
FreeMem(varipointer, (long)sizeof(pointer));
--
Phone: (914) 359-2900 x340
Post: Lamont-Doherty Geological Observatory / Palisades, NY 10964
USENET: {ihnp4, decvax, seismo} philabs!lamont!adam
ARPA: lamont!adam@columbia.eduadam@lamont.Columbia.edu (adam levin) (03/28/88)
In article <442@lamont.Columbia.edu>, I, adam@lamont.Columbia.edu (adam levin) wrote: > > I have a 'C' array which needs to be in chip RAM. The examples I have found > declare the array, AllocMem some chip RAM, and copy the array into it. > This is wasteful if all one has is chip RAM, or if the program was linked > with Manx's +C option. I wrote the following routine, and I'd like to know ... I soon received a message from Dale Luck informing me that: ] ... There already is an exec function call 'TypeOfMem'. ] You pass in the address, and it returns the flag bits associated ] with that memory. ] NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER ] use fixed addresses for deciding where chip memory is. It is going to ] increase in size with the new chips as well as it may move to a new ] base with new systems. ] From: amiga!boing!dale@prls (Dale Luck) So never mind! -Adam -- Phone: (914) 359-2900 x340 Post: Lamont-Doherty Geological Observatory / Palisades, NY 10964 USENET: {ihnp4, decvax, seismo} philabs!lamont!adam ARPA: lamont!adam@columbia.edu
kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) (03/29/88)
In article <442@lamont.Columbia.edu> adam@lamont.Columbia.edu (adam levin) writes: >I have a 'C' array which needs to be in chip RAM. The examples I have found >declare the array, AllocMem some chip RAM, and copy the array into it. I'm not sure of all the details, but I'm assuming that you have a lot of static data. Two solutions come to mind: (1) keep the data in a file, allocate a chip array, initialize from the file. (2) create a static data segment, forcing everything into chip, then LoadSeg() it. Neither solution is very elegant. Compilers need another storage class. Ken Chiu
papa@pollux.usc.edu (Marco Papa) (03/29/88)
In article <2210@phoenix.Princeton.EDU| kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) writes: |In article <442@lamont.Columbia.edu| adam@lamont.Columbia.edu (adam levin) writes: ||I have a 'C' array which needs to be in chip RAM. The examples I have found ||declare the array, AllocMem some chip RAM, and copy the array into it. | |I'm not sure of all the details, but I'm assuming that you have a lot of |static data. Two solutions come to mind: (1) keep the data in a file, |allocate a chip array, initialize from the file. (2) create a static |data segment, forcing everything into chip, then LoadSeg() it. Neither |solution is very elegant. Compilers need another storage class. Both Lattice C and MANX C have link-time switches that allow you pto ut all or some of the data in a hunk that will be loaded in CHIP memory. Details in the manuals. -- Marco Papa -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bryce@eris (Bryce Nesbitt) (03/29/88)
[A perfect ".tech" topic...] In article <> adam@lamont.Columbia.edu (adam levin) writes: > >I wrote the following routine, and I'd like to know >if this is a reasonable way to avoid the unnecessary copy [to CHIP ram]. It is reasonable to check if the memory is already in chip, and not copy if it is. Your method is unreasonable. >/* MemType - Given a starting address and a length, returns > either MEMF_CHIP, MEMF_FAST, or both. > 25-Mar-1988 aklevin */ >... >#define FAST_STARTS 0x80000L That is not the start of fast memory. Remember 1 Megabyte chip memory rummors? Two megabyte rummors? 2 Gigabyte chip memory rummors? Face it, you just don't know. The system already has a call all set up for this use. TypeOfMem(). It is in exec library. It takes the base of your memory block, and tells you what type of memory it is in. Blocks of memory never span types of memory. Since you may be one of the thousands that does not have proper V1.2 Kickstart documentation, here is the "autodoc" for TypeOfMem(), duplicated here without permission of the Copyright holder, Commodore-Amiga, Inc.: exec.library/TypeOfMem NAME TypeOfMem -- determine attributes of a given memory address SYNOPSIS attributes = TypeOfMem(address) D0 A1 [Available with V1.2 Kickstart and beyond] FUNCTION Given a RAM memory address, return its known memory attributes. These known memory attributes are similar to those specified when the memory was allocated: MEMF_CHIP and MEMF_FAST. If the address is not in known RAM-space, a zero will be returned. This is typical for all control spaces, ROM, RAM-ROM, and the hardware expansion interface. INPUT address - a memory address RESULT attributes - a long word of memory attribute flags. If the address is not in known RAM, zero is returned. SEE ALSO AllocMem() |\_/| . ACK!, NAK!, EOT!, SOH! {O_o} . Bryce Nesbitt (") BIX: mleeds (temporarily) U USENET: bryce@eris.berkeley.EDU -or- ucbvax!eris!bryce
kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) (03/30/88)
In article <7923@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes: >Both Lattice C and MANX C have link-time switches that allow you pto ut all >or some of the data in a hunk that will be loaded in CHIP memory. Details >in the manuals. Hmm. . .from my reading of my Manx manual, you can only specify location at the level of code, initialized data, and uninitialized data. Thus you would have to put *all* of your initialized variables in CHIP, even if only 10% needed to be. Am I missing something? Ken Chiu
papa@pollux.usc.edu (Marco Papa) (03/30/88)
In article <2221@phoenix.Princeton.EDU| kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) writes: |In article <7923@oberon.USC.EDU| papa@pollux.usc.edu (Marco Papa) writes: ||Both Lattice C and MANX C have link-time switches that allow you pto ut all ||or some of the data in a hunk that will be loaded in CHIP memory. Details ||in the manuals. | |Hmm. . .from my reading of my Manx manual, you can only specify location |at the level of code, initialized data, and uninitialized data. Thus you |would have to put *all* of your initialized variables in CHIP, even if |only 10% needed to be. Am I missing something? No, you're not. I should have been more specific: Lattice allows you to put all or SOME data in CHIP RAM; MANX allows you to put ALL or NONE of the intializeed or non-initialized data in CHIP RAM. Sorry for the confusion. -- Marco Papa -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
haitex@pnet01.cts.com (Wade Bickel) (03/30/88)
papa@pollux.usc.edu (Marco Papa) writes: >In article <2210@phoenix.Princeton.EDU| kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) writes: >|In article <442@lamont.Columbia.edu| adam@lamont.Columbia.edu (adam levin) writes: >||I have a 'C' array which needs to be in chip RAM. The examples I have found >||declare the array, AllocMem some chip RAM, and copy the array into it. >| >|I'm not sure of all the details, but I'm assuming that you have a lot of >|static data. Two solutions come to mind: (1) keep the data in a file, >|allocate a chip array, initialize from the file. (2) create a static >|data segment, forcing everything into chip, then LoadSeg() it. Neither >|solution is very elegant. Compilers need another storage class. > >Both Lattice C and MANX C have link-time switches that allow you pto ut all >or some of the data in a hunk that will be loaded in CHIP memory. Details >in the manuals. In Modula-2 I handle this kind of problem as follows. First create a pointer to an ARRAY of the type you want, then use the Alloc function of your choice to create the memory allocation on the end of your pointer. Works great for me. I do it all the time and I know this works in C because I used to do it with MANX as well. Good Luck, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM