Prev: A bug and a related mini-challenge re LSQ
Next: A bug and a related mini-challenge re LSQ [analogy with LR]
From: tan66 on 4 May 2008 13:32
On 4 mai, 15:21, Claudio Lapilli <pleasedonts...(a)isp.com> wrote:
> Hello,
>
> On May 3, 5:59 am, tan66 <briancon_tan...(a)yahoo.fr> wrote:
>
> > Hello
>
> > I made a program with hpgcc which push and pop objects in/from the rpl
> > stack. I also
> > do some sat_poke on rpl objects onto the stack. Is the rpl adress
> > (SAT_STACK_ELEMENT addr field)
> > of an rpl object on stack may change after a sat_createtemp or
> > sat_pushptr?
>
> No, hpgcc does not perform an automatic garbage collection, therefore
> an object address remains constant until you exit your C program.
>
>

Thank you for the answer. It is exactly what I wanted.

>
> > On other question: does anyone made a sat_stack_rot?
>
> There's not much use for it, since you can use ...pick(n) to access
> any stack level directly. You can quickly write a rot function, by
> popping all 3 values off the stack, and then pushptr them in the
> proper order.
>
> Claudio

I didn't think about how to do it. Your solution is very simple and I
can write it.

Tanguy


From: John H Meyers on 4 May 2008 13:48
On Sun, 04 May 2008 08:21:38 -0500, Claudio Lapilli wrote:

> hpgcc does not perform an automatic garbage collection, therefore
> an object address remains constant until you exit your C program.

> You can quickly write a rot function,
> by popping all 3 values off the stack,
> and then pushptr them in the proper order.

Since I know nothing, but just have curiosity,
I can ask "real dumb" questions from pure ignorance
(or feel free to refer me to fine manuals :)

Is there a GC upon (or before) initial entry?

If not, does "pop/push" affect RPL stack memory,
which could have been very close to limit
(e.g. one word away from needing GC) to begin with?

In any case, there must always be some limit,
at which points the RPL stack(s) either overflow or underflow?

Is there any access to RPL "return" stack and "environments"?

Thanks for all the info you post,
which I always know will be enlightening to read,
whether I know the whole story or not.

-[ ]-
From: Claudio Lapilli on 5 May 2008 19:40
Hi,

On May 4, 1:48 pm, "John H Meyers" <jhmey...(a)nomail.invalid> wrote:

> Since I know nothing, but just have curiosity,
> I can ask "real dumb" questions from pure ignorance
> (or feel free to refer me to fine manuals :)

Well... we don't have such good documentation, so I can't really use
the usual RTFM. It's not my style anyway.

>
> Is there a GC upon (or before) initial entry?

Yes, there is a GC if you call it using PrRUN, you can skip it if you
execute it using the other commands (PrLNK and PrJMP), in case you
don't like the speed penalty.
Let me clarify that I'm talking about HPGCC 2.0. The new version
(HPGCC3) behaves completely different.

>
> If not, does "pop/push" affect RPL stack memory,
> which could have been very close to limit
> (e.g. one word away from needing GC) to begin with?

You can always run a program under very low memory conditions, with GC
or not. In such case, push will fail (return without pushing the
value) if there's not enough memory.

>
> In any case, there must always be some limit,
> at which points the RPL stack(s) either overflow or underflow?

Overflow, yes, but it is under control, since the C program will
simply refuse to push any new objects on the stack when memory is
insufficient.
Underflow can't really happen, since you can't have less than 0 items
on the stack :-). pop will simply fail on an empty stack

>
> Is there any access to RPL "return" stack and "environments"?

No, we have no such functions. But using peek() and poke() you can
push values in the return stack "manually". It's not very useful,
though, since you can't touch anything on the RPL stream or your C
program will crash on return.

I hope this satisfies your curiosity,
Claudio
From: JYA on 5 May 2008 23:23
Hi

On 2008-05-06 09:40:37 +1000, Claudio Lapilli <pleasedontspam(a)isp.com> said:
> Overflow, yes, but it is under control, since the C program will
> simply refuse to push any new objects on the stack when memory is
> insufficient.
> Underflow can't really happen, since you can't have less than 0 items
> on the stack :-). pop will simply fail on an empty stack

Last time I used HPGCC, you couldn't tell unfortunately, weither the
push worked or not. it wouldn't return a value letting you that it
worked. If it couldn't push a value on the stack, it would simply do
nothing

As such, I had to manually test the amount of memory available before I
called push.

JY

--
They who would give up an essential liberty for temporary security,
deserve neither liberty or security (Benjamin Franklin)

From: John H Meyers on 5 May 2008 23:48
On Mon, 05 May 2008 18:40:37 -0500, Claudio Lapilli wrote:

> I hope this satisfies your curiosity,

Very well! -- thanks.

[r->] [OFF]
 |  Next  |  Last
Pages: 1 2
Prev: A bug and a related mini-challenge re LSQ
Next: A bug and a related mini-challenge re LSQ [analogy with LR]