cosell@bbn.com (Bernie Cosell) (04/07/89)
[are you allowed to ask "basic" questions in the .tech group... I guess I'll
find out..:-)]
I have a bunch of Basic programs which have the need to move LARGE quantities
of data in and out. I was looking at an old ABasiC program and I noticed that
_it_ used a thing called "bload". Now I don't exactly know what that does, but
I guessed it did a "binary load", and that seemed like a great idea. SO...
I whipped up some simple code to do a big xRead to suck the stuff in in one
gulp. My problem: how can I do that from a *subroutine*? The problem is
passing in the address of the place where the loading is to go (or the address
of the stuff to be dumped for bdump). I had originally inteded to do it with:
SUB BLoad (FileName$, Address&) STATIC
and then have the guy on the outside call it as
CALL BLoad ("datafile.dat", VARPTR(dataarrar(1)))
But then I realized that since Basic *moves* variables around, the "Address&"
will be mostly useless by tthe time I get around to the xRead(). Two
questions:
a) is there some way to _beat_ the var-moving problem? Passing in the
memory-address explicitly is surely the most convenient scheme, if I could
make it work, and
b) if not, how then could I declare that subroutine? I'm OK with the program
always reading into a array (hard to imagine that this is all that useful for
reading in a single value, and even then you can just set up a one-long
array). BUT: how to get the *types* to match??? I can easily do:
SUB BLoad (FileName$, Array()) STATIC
and do the VARPTR inside the subroutine, but how do I handle arry-of-shorts
versus array-of-floats, etc.
Thanks
__
/ ) Bernie Cosell
/--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_ cosell@bbn.compost@cpsc.ucalgary.ca (The POSTMAN) (04/08/89)
In article <38410@bbn.COM>, cosell@bbn.com (Bernie Cosell) writes: > [are you allowed to ask "basic" questions in the .tech group... I guess I'll > find out..:-)] > > I have a bunch of Basic programs which have the need to move LARGE quantities > of data in and out. I was looking at an old ABasiC program and I noticed that > _it_ used a thing called "bload". Now I don't exactly know what that does, but [Stuff Deleted] > will be mostly useless by tthe time I get around to the xRead(). Two > questions: > a) is there some way to _beat_ the var-moving problem? Passing in the > memory-address explicitly is surely the most convenient scheme, if I could > make it work, and The easiest way to do this is actually using routines from EXEC to do this for you. As like in 'C' just allocate the memory you need. The operating system returns a pointer to the memory you just allocated. Something like this: LIBRARY "exec.library" 'This will get open the exec.library for you to use ' note the 'exec.bmap must be in the current dir. DECLARE FUNCTION AllocMem& LIBRARY 'I think this is the right syntax ?? Mem_Pointer& = AllocMem(Size (in bytes),Flags) Note: Mem_Pointer has to be a long (32-bit) Size is in bytes (Exec will round it up to the nearest 8 byte block) Flags - things like CHIP or FAST or CLEAR (etc..), values can be found in any C/asembler include files The result is a chunk of memory at location Mem_Pointer to play with your hearts content. > b) if not, how then could I declare that subroutine? I'm OK with the program > always reading into a array (hard to imagine that this is all that useful for > reading in a single value, and even then you can just set up a one-long > array). BUT: how to get the *types* to match??? I can easily do: > SUB BLoad (FileName$, Array()) STATIC > and do the VARPTR inside the subroutine, but how do I handle arry-of-shorts > versus array-of-floats, etc. This way you can easily have a SUB declared passing it the FileName, Pointer and probably the size. > > Thanks You're Welcome! > __ > / ) Bernie Cosell > /--< _ __ __ o _ BBN Sys & Tech, Cambridge, MA 02238 > /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com Lenny Post University of Calgary Member/Executive of AMUC (The AMiga Users of Calgary) "The Cat came back, the very next day!" "I will not buy this record, It is scratched" - Monty Python "No. Amiga is not dead. Hell, it's not even tired." --- Leo. L. Schwab