[A83] Re: allocating uninitialized memory? + _insertmem

[Next][Index][Thread]

[A83] Re: allocating uninitialized memory? + _insertmem

how about opening an edit buffer?  i don't believe these modify the vat,
they simply keep you from creating or removing variables, pushing or popping
anything on fp or op stacks.  Then you'll have all the free ram on the calc
to work with.  you wouldn't be able to use absolute addressing on this ram
though.

brandon
----- Original Message -----
From: "Nicolas Gilles" <eee20154@port.ac.uk>
To: <assembly-83@lists.ticalc.org>
Sent: Saturday, May 31, 2003 4:19 PM
Subject: [A83] Re: allocating uninitialized memory? + _insertmem


> Actually.. with appvars you get the exact same result as with programs...
> appvars and programs are exactly the same except that they have a
different
> identifier ... so that appvars don't appear in the programs list (and
can't
> be executed) and vice versa...
> so if you were to port to 83, you would just change the name of the appvar
> to something that is invisible to the programs list menu....and change the
> object type to program.
>
> Anyways ... I think this method of creating a variable big enought to hold
> all the data is useful only in few circunstances... in most cases the
> memory, going to be scratch memory will be used only in a contiguous part
of
> the program in which you will unlikely do stuff that will require the TIOS
> allocating dea llocating memory and messing everything about ...
>
> The only advantage of creating a var and storing the stuff there to
operate
> on is that you could allow to interrupt the process and continue later, or
> at the smae time you process the data contained within you ABSOLUTELY HAVE
> to do memory messing operations..(I think this is highly unlikely)... In
> anyother case this method just created unwated overhead...
>
> -Nicolas Gilles
> ----- Original Message -----
> From: "Gavin Olson" <gtolson@comcast.net>
> To: <assembly-83@lists.ticalc.org>
> Sent: Saturday, May 31, 2003 14:37
> Subject: [A83] Re: allocating uninitialized memory? + _insertmem
>
>
> > At 09:10 AM 5/31/03 -0400, you wrote:
> > >what about appvars??
> >
> >
> > They make porting to 83 very difficult - with using the scratch space,
you
> > just have a #ifdef structure; with appvars you simply can't do it on the
> 83.
> >
> >
> >
> >
> > >At 03:35 AM 5/31/03, you wrote:
> > >
> > >> > >It's still sloppy, though.  You can't absolutely guarantee that
> another
> > >> > >program won't already exist with the same name - although you
could
> > >> > >manually
> > >> > >check that, I suppose.
> > >> >
> > >> > That seems like a silly arguement.  If your program is named Bingo,
> say,
> > >> > create a program named BINGODATA or whatever.  Talking about
> garantees
> > >>isn't
> > >> > going to get you anywhere, and you can't absolutely garantee that
> there
> > >>will
> > >> > be free RAM space no matter what method you use.  At least this way
> you
> > >>can
> > >> > garantee that the system isn't going to scribble all over your data
> > >>because
> > >> > you put it into what is essentially scratch space.
> > >> >
> > >> >
> > >> >
> > >> >
> > >>Well, who's to say that there isn't already a program on the
calculator
> > >>called "BINGODATA" (if programs could have 9 character names, that
is)?
> And
> > >>besides, the only reason you would use this method that I can think of
> would
> > >>be to save data for future use.  But then you run into troubles with
> keeping
> > >>data in sync - making sure that the user didn't delete the save
program,
> or
> > >>whether it's archived or not etc.  IMHO, it is generally better to use
a
> > >>shell that supports writeback or write the data back yourself when you
> need
> > >>to store vital data.
> > >>
> > >>Using the free RAM space for temporary buffers/lookup tables or
whatever
> is
> > >>a cleaner method with a hell of a lot less overhead.
> > >
> >
> >
> >
> >
>
>
>
Follow-Ups: