I'm building my first program in SysRPL. Actually I have on the stack 4
reals and I need to manage them. But I want to use my command with ZINT (eg.
number without decimal point), too.
I arranged some code like this:
* The Ultimate SysRPL Program
xNAME TUSRPLP
::
CK4NOLASTWD
::
BINT5 BINT1 DO
::
CK1&Dispatch
real
::
... do something with the real number
;
# FF
::
^Z>R
... do something with the real number
;
;
LOOP
;
;
The program runs OK if I have on the stack 4 real numbers but reset the
emulator if I have on the stack a ZINT.
Where is my error?
Massimo Santin
|
|
0
|
|
|
|
Reply
|
Massimo
|
4/16/2007 8:16:03 PM |
|
Massimo Santin (at GMail) wrote:
> I'm building my first program in SysRPL. Actually I have on the stack 4
> reals and I need to manage them. But I want to use my command with ZINT
> (eg. number without decimal point), too.
> I arranged some code like this:
>
> * The Ultimate SysRPL Program
> xNAME TUSRPLP
> ::
> CK4NOLASTWD
> ::
> BINT5 BINT1 DO
> ::
> CK1&Dispatch
> real
> ::
> ... do something with the real number
> ;
> # FF
> ::
> ^Z>R
> ... do something with the real number
> ;
> ;
> LOOP
> ;
> ;
>
> The program runs OK if I have on the stack 4 real numbers but reset the
> emulator if I have on the stack a ZINT.
> Where is my error?
>
> Massimo Santin
First, I'm a beginner SysRPL programmer. So take this post with a grain of
salt. :)
With that said,... No need to manually convert ZINTs yourself. CK1&Dispatch
does a CK1, then a CK&DISPATCH1, which "converts zints to reals" (Prog. In
SysRPL). So, you can aviod duplication of code by removing the # FF stuff.
Another option is to simply use CKREAL inside your DO...LOOP, and avoid the
dispatching overhead.
Or, I think you may want to try something like this:
::
CK4NOLASTWD
::
CK&DISPATCH1
# 1111
::
(Your DO...LOOP w/out error checking. Don't forget to 4ROLL!)
;
;
;
There's probably also a way to avoid the DO...LOOP...
HTH,
Greg M.
|
|
0
|
|
|
|
Reply
|
Greg
|
4/17/2007 12:30:37 AM
|
|
I investigated and I wrote this simple code:
xNAME TEST1
::
CK1NOLASTWD
CK1&Dispatch
# FF
::
^Z>R
;
;
The code check for 1 parameter, check if the parameter is a ZINT, if the
parameter is a ZINT convert it to a real.
Then I tried to execute it (in RPN mode)
10 ENTER TEST1
I expect to see a 10. on stack at level 1. But the emulator reset. He
doesn't like the ^Z>R command.
Why?
Massimo Santin
|
|
0
|
|
|
|
Reply
|
Massimo
|
4/17/2007 1:14:01 AM
|
|
Massimo Santin (at GMail) wrote:
> I'm building my first program in SysRPL. Actually I have on the stack 4
> reals and I need to manage them. But I want to use my command with ZINT
> (eg. number without decimal point), too.
> I arranged some code like this:
>
> * The Ultimate SysRPL Program
> xNAME TUSRPLP
> ::
> CK4NOLASTWD
> ::
> BINT5 BINT1 DO
> ::
> CK1&Dispatch
> real
> ::
> ... do something with the real number
> ;
> # FF
> ::
> ^Z>R
That's were your problem is.
you need to type:
FLASHPTR Z>R
not ^Z>R
JY
|
|
0
|
|
|
|
Reply
|
Jean
|
4/17/2007 1:44:30 AM
|
|
"Jean-Yves Avenard" <me@privacy.net> wrote in message
news:4624267f$0$25439$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> That's were your problem is.
> you need to type:
> FLASHPTR Z>R
> not ^Z>R
>
> JY
Correct! Thank you.
But I didn't found any reference on FLASHPTR in RPLMAN or in "Programming in
System RPL".
MS
|
|
0
|
|
|
|
Reply
|
Massimo
|
4/17/2007 2:19:19 AM
|
|
> Correct! Thank you.
> But I didn't found any reference on FLASHPTR in RPLMAN or in "Programming in
> System RPL".
That's becuase it is the type of syntax used by debug4x (which uses
and older compiler sytem the name of which I am forgetting).
TW
|
|
0
|
|
|
|
Reply
|
TW
|
4/17/2007 2:22:34 AM
|
|
Massimo Santin (at GMail) wrote:
> Correct! Thank you.
> But I didn't found any reference on FLASHPTR in RPLMAN or in
> "Programming in System RPL".
Flash pointer didn't exist at the time rplmanual was written and it was
never updated.
JY
|
|
0
|
|
|
|
Reply
|
Jean
|
4/17/2007 2:49:44 AM
|
|
Massimo Santin (at GMail) wrote:
> Correct! Thank you.
> But I didn't found any reference on FLASHPTR in RPLMAN or in
> "Programming in System RPL".
Please note that you could shrink your program by a factor of two.
In your loop, you could remove the #FF :: ^>R ... ; all together
as if nothing match the real test and a zint is found, the zint would
automatically be converted into real.
So if the code following Z>R is the same as the code following the real
case, this code is redundant.
JY
|
|
0
|
|
|
|
Reply
|
Jean
|
4/17/2007 2:55:33 AM
|
|
"TW" <timwessman@gmail.com> wrote in message
news:1176776554.372854.193480@o5g2000hsb.googlegroups.com...
>> Correct! Thank you.
>> But I didn't found any reference on FLASHPTR in RPLMAN or in "Programming
>> in
>> System RPL".
>
> That's becuase it is the type of syntax used by debug4x (which uses
> and older compiler sytem the name of which I am forgetting).
>
> TW
I suppose the only thing I need to manage these problems is the necessary
knowledge! ;-)
MS
|
|
0
|
|
|
|
Reply
|
Massimo
|
4/17/2007 3:10:46 AM
|
|
"Jean-Yves Avenard" <me@privacy.net> wrote in message
news:46243727$0$25481$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> So if the code following Z>R is the same as the code following the real
> case, this code is redundant.
Actually the code is not the same. I'm building as exercise a simple IPv4
calculator and I'm using some esplicit multiplications by some 2^N factors.
This piece of (ugly) code is the routine that converts 4 octets to a 32 bits
number. I need to combine 4 number into the stack with different factors and
make some calculations. When I have zints I need to make some explicity
conversion.
Probably I will rewrite this routine. But, before that, I need to play with
form. I want to write some programs similar to the numeric equation solver.
BTW SysRPL is an interesting environment.
MS
|
|
0
|
|
|
|
Reply
|
Massimo
|
4/17/2007 3:36:52 AM
|
|
On 17 Apr, 04:19, "Massimo Santin \(at GMail\)"
<massimo.san...@gmail.com> wrote:
> "Jean-Yves Avenard" <m...@privacy.net> wrote in message
>
> news:4624267f$0$25439$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
>
> > That's were your problem is.
> > you need to type:
> > FLASHPTR Z>R
> > not ^Z>R
>
> > JY
>
> Correct! Thank you.
> But I didn't found any reference on FLASHPTR in RPLMAN or in "Programming=
in
> System RPL".
>
> MS
Ciao Massimo.
Browsing Kalinowski&Dominik's book I found this:
"For supported flashpointer entries (whose names always start with =CB=86),
you have to prefix the entry=E2=80=99s name with FPTR2. So, to call the
flashpointer
command =CB=86Z>R, you will have to include this in your program:
FPTR2 =CB=86Z>R"
You can find it on page 437, paragraph A.4.1, "MASD and the Different
Kinds of Entries".
Hope this helps.
Best regards.
Giancarlo
|
|
0
|
|
|
|
Reply
|
Giancarlo
|
4/17/2007 6:25:29 AM
|
|
Giancarlo wrote:
> Ciao Massimo.
> Browsing Kalinowski&Dominik's book I found this:
> "For supported flashpointer entries (whose names always start with ˆ),
> you have to prefix the entry’s name with FPTR2. So, to call the
> flashpointer
> command ˆZ>R, you will have to include this in your program:
> FPTR2 ˆZ>R"
This is using MASD, not the HPTools
JY
|
|
0
|
|
|
|
Reply
|
Jean
|
4/17/2007 12:26:02 PM
|
|
On Mon, 16 Apr 2007 21:55:33 -0500:
What JYA says solves everything, as to programs
which want to treat Zints the same as reals.
Check out this caution from Bill Wickes
about using "CK1&Dispatch" in place of CK&DISPATCH0/1
from "DISPATCH.DOC" on Goodies Disk #9:
http://www.hpcalc.org/details.php?id=3D240
http://www.hpcalc.org/hp48/compilations/horn/horn9.zip
Quoted below:
(Comp.sys.hp48) Option:
Item: 1024 by _joehorn@hpcvbbs.cv.hp.com [Joseph K. Horn]
Subj: G/GX Auto List Processing Update
Date: 10 Jun 1993
----------
Resp: 6 of 6 by billw@hpcvra.cv.hp.com [William C Wickes]
Date: 18 Jun 1993
Automatic list processing is a property of CK1&Dispatch ... CK5&Dispatch=
,
which are intended only to be used as the first objects within keyword
secondaries. It is *not* a property of CK&DISPATCH0/1. The latter word=
s
are used for dispatching at various levels; it would have been very
dangerous to change their behavior.
Joseph Horn writes:
> To answer that, I threw together a tiny program that started with
> CK2&Dispatch, and it automatically had the new list processing
> ability. But then I inserted a NOP between the :: and the
> CK2&Dispatch, and the list processing went away!
That's not all that might go away. CKn&Dispatch assume that they
are the first objects in a keyword secondary, and in particular that
that secondary is preceded by a property list code and a command name.
They should not be used elsewhere. I know that's not the point of
Joe's example, but it makes me cringe when I see the CKn&Dispatch
words flung around.
Bill Wickes
HP CVD
|
|
0
|
|
|
|
Reply
|
John
|
4/17/2007 9:02:56 PM
|
|
On Mon, 16 Apr 2007 20:14:01 -0500:
> xNAME TEST1
> ::
> CK1NOLASTWD
> CK1&Dispatch <=3D=3D=3D NOT ALLOWED HERE!
Use CK&DISPATCH1 instead;
see the quote from Bill Wickes, posted earlier.
Per Mika Heiskanen's ENT_SRT (a misnomer):
CK&DISPATCH0 Dispatch on stack arguments
CK&DISPATCH1 Dispatch on stack arguments, strip tags if necessary
CK&DISPATCH2 ???
http://www.hpcalc.org/search.php?query=3Dent_srt
[r->] [OFF]
|
|
0
|
|
|
|
Reply
|
John
|
4/17/2007 9:28:07 PM
|
|
John H Meyers wrote:
> On Mon, 16 Apr 2007 20:14:01 -0500:
>
>> xNAME TEST1
>> ::
>> CK1NOLASTWD
>> CK1&Dispatch <=== NOT ALLOWED HERE!
you can use it there, but in case of an error, you'll get a meaningless
name like:
!@#!@$!@ Error:
Too few arguments
JY
|
|
0
|
|
|
|
Reply
|
Jean
|
4/18/2007 12:35:40 AM
|
|
Now I understand better the "CK & DISPATCH" mechanism. Thank you to
everybody.
If you are interested I show you my small progress in the source code below.
Note all the CK#&Dispatch that make the right conversions from ZINT to real
and that are placed before a secondary. You all (people from the newsgroup)
teached something to me, I think. :-) For a beginner is very important to
have this type of help to understand the environment.
In the next future probably I will return with some "style" and code
questions about user interface and Inform. I want to write an IP calculator
with an interface behaviour similar to an equation solver.
As first impressions on SysRPL I want to tell that:
1. the environment is interesting and very similar to some virtual machines
2. the language is cryptic. Pheraps the same functionalities with
alternative syntax, more consistent and and/or with more verbose words could
be good (SysRPL more like UserRPL)
3. the documentations that I found is good but you need some sort of
beginners guide
4. this newsgroup is fantastic
5. programming on HP calc is fun
Massimo Santin
------
I'm writing an IPv4 Calculator as an exercise to understand SysRPL (I
already written it in UserRPL).
Actually in my IP Calculator program I represent an IP address as an (32
bit) HXS number. I wrote two routines tha convert an IP address from a stack
representation to an HXS and viceversa. 192.168.1.2 is represented into the
stack as 192 168 1 2 (eg 192 in level 4).
STIP2B: 192 168 1 2 -> # C0A80102h
B2STIP: # C0A80102h -> 192 168 1 2
With this two routines I can write the other typical routines to manipulate
IP address using HSX arithmetic and logical operations.
The next step will be to write an interface using Inform that take IP data
and make typical IP Calculator calculations.
Meantime I thought that can be useful to have these commands to use in
UserRPL. Using HSX or 4 numbers into the stack is not very friendly for
humans. I decided to introduce a representation of IP address as a 4 numbers
list: 192.168.1.2 is representend as { 192. 168. 1. 2. } (ZINT or real, not
important).
IP\->B: { 192. 168. 1. 2. } -> # C0A80102h
B\->IP: # C0A80102h -> { 192. 168. 1. 2. }
An hypotetical user can write programs that ask IP addressess as lists,
convert them into an HXS, make calculations, convert results in IP addresses
as list.
Actually my code is so written:
( convert an IP address represented as { X. X. X. X. } to an HXS )
xNAME IP\->B
::
CK1&Dispatch
#00005 ( a list in level 1 )
::
FLASHPTR DUPCKLEN{}
#4 #= ITE ( check if the list contains 4 elements)
::
( TODO check list_elment is an real/ZINT and if 0 <= list_element <=
255 )
INCOMPDROP
STIP2B
;
::
SETSIZEERR
;
;
;
( convert an HXS to an IP address represented as { X. X. X. X. } )
xNAME B\->IP
::
CK1&Dispatch
#0000B
::
B2STIP
#4
{}N
;
;
( convert 4 number into stack to an HXS )
NULLNAME STIP2B
::
CK4&Dispatch
#01111 ( 4 real or ZINT in level 1,2,3,4 )
::
%># SWAP
%># bitSLB bitOR SWAP
%># bitSLB bitSLB bitOR SWAP
%># bitSLB bitSLB bitSLB bitOR
;
;
( convert an HXS to 4 numbers into stack )
NULLNAME B2STIP
::
CK1&Dispatch
#0000B ( an HXS in level 1 )
::
DUP # FF #>HXS bitAND HXS>% SWAP bitSRB
DUP # FF #>HXS bitAND HXS>% SWAP bitSRB
DUP # FF #>HXS bitAND HXS>% SWAP bitSRB
# FF #>HXS bitAND HXS>% SWAP
#4 reversym DROP
;
;
|
|
0
|
|
|
|
Reply
|
Massimo
|
4/18/2007 12:42:08 AM
|
|
On Tue, 17 Apr 2007 19:35:40 -0500:
| xNAME TEST1
| ::
| CK1NOLASTWD
| CK1&Dispatch <=3D=3D=3D NOT ALLOWED HERE!
> you can use it there
Will it work with list processing?
CK&DISPATCH1 would certainly appear safer and more normal, no?
Why would one ever even want to do two consecutive "CK1", since
the second word above already includes the first word's function?
Even though I'm no authority, I'd suggest using *either*
"CK1&Dispatch" to begin with (and alone),
or else the pair CK1NOLASTWD and CK&DISPATCH1,
which separates the "CK1" function from the "dispatch" function
(while also sacrificing list processing).
[r->] [OFF]
|
|
0
|
|
|
|
Reply
|
John
|
4/18/2007 1:57:29 AM
|
|
On Tue, 17 Apr 2007 19:42:08 -0500, Massimo Santin wrote:
> #00005 ( a list in level 1 )
> #0000B
> #01111 ( 4 real or ZINT in level 1,2,3,4 )
> #0000B ( an HXS in level 1 )
o You don't have to explicitly write the leading zeros,
because all "system binary" objects are 20 bits anyway,
unlike variable-length hex strings "HXS length digits";
note that any type codes requiring two digits "xF" will thus reduce
the number of levels for which type codes may be specified at all!
(this fortunately is highly unlikely ever to arise,
unless one demands several of the new "integer" arguments #...FF).
o Some compilers may generate 5-byte in-line objects
(system binary, type 20) for # nnnnn,
whereas built-in symbols #5 or "list", FIVE, BINT5, etc.
generate a 2.5-byte pointer to a built-in constant --
not that such tiny savings mean much these days,
but someone once won an HP48GX 1MB memory card in a contest,
just by shaving milliseconds off a program :)
[r->] [OFF]
|
|
0
|
|
|
|
Reply
|
John
|
4/18/2007 2:30:04 AM
|
|
John H Meyers wrote:
> Will it work with list processing?
Interesting question, I'm not sure I can answer this one without
investigating the code ; I can't remember.
>
> CK&DISPATCH1 would certainly appear safer and more normal, no?
>
> Why would one ever even want to do two consecutive "CK1", since
> the second word above already includes the first word's function?
Actually, if there's no argument on the stack, you will always get a
valid error message, as CK1&Dispatch will consider it will find before
the program, the 6 nibbles containing the xNAME value.
Here it would be the first CK1NOLASTWD erroring out
Jean-Yves
|
|
0
|
|
|
|
Reply
|
Jean
|
4/18/2007 4:19:35 AM
|
|
Hi John,
I used all the bits for clarity. A thing that make me bring the wrong way
is, for example, the use of list symbol in place of #00005. I considered the
CK&... family more like as a switch/case construct (in C language). Using
the entire 24 bit word make clear that CK&... family use the word as a
descriptor for parameters more like as the prototypes of a polymorphic
function (as in C++ language). I know that the analogies are a bit streched
but I think they make my point (I need to forget my roots in C and consider
my roots in Smalltalk to understand SysRPL). The fact that RPLMan e the
SystemRPL Guide use as example a dissassembled TYPE command contributed to
this misunderstanding (one parameter, one big switch/case that return one
result). When you read more carefully the two manuals you find all the right
informations in the right place but... I'm a beginner!
However I understand your concern about memory and I will change the code
with a better comment that explain the fact.
MS
|
|
0
|
|
|
|
Reply
|
Massimo
|
4/18/2007 7:15:46 AM
|
|
|
19 Replies
148 Views
(page loaded in 0.201 seconds)
|