Can we imagine these new HP50g...
Didier
manjo
news:4495a718$0$32625$626a...@news.free.fr...
> ... in native ARM code ? Or is it a stupid idea...
not stupid,
however imagine man-hours invested in Saturn programs, concepts etc...
that's why you shouldn't expect Saturn platform to disappear entirely over
night.
Emulator is a perfect way to keep compatibility at reasonable speed (fastest
up to date)
on the other hand effective way to execute native ARM is great !
ARM processors (RISC) are simple and effective perfect choice.
Saturn based software (even emulated) has numerous advatages too
I assure you it's almost perfect concept !!
manjo
P.S. why have one when you can have both ?
johnet123
Didier wrote:
> ... in native ARM code ? Or is it a stupid idea...
Although the below URL does not add any new information, it might be
worthwhile to visit it occasionally to see if anything new has been
added.
James M. Prange
> .... in native ARM code ? Or is it a stupid idea...
I'm not sure what you mean; all UserRPL commands written in
"native ARM code" with no SysRPL or assembly language code in
them?
I'm not even sure of what you mean by "native ARM code"; perhaps
the 0s and 1s of machine language? Or maybe a high-level language
like C to be compiled to run on the underlying ARM processor?
I rather like UserRPL, and SysRPL, and Saturn assembly language;
all have their places (and should definitely be kept), and now
accessing the underlying ARM processor has its place in the
calculator too.
If a command or instruction can be made much faster, or a very
frequently used operation (or sequence) can be made somewhat
faster, by rewriting it in a lower level language, then doing so
may well be worthwhile, but it seems to me that as a general rule,
the lower the level of the language, the more bytes it takes to
get the job done, and the harder it is to write, debug, or modify
the code. Of course if something that we want to do just can't be
accomplished with the current RPL commands and assembly language
instructions, but can be by using ARM code, then it would be
worthwhile to write a new command or instruction using ARM code.
I'd think it better to concentrate mostly on getting the bugs out
of the system, and use ARM code for particularly time-consuming
operations and where it's needed for new operations.
--
Regards,
James
Larry Smith
> ... in native ARM code ? Or is it a stupid idea...
No. What is needed is a good binary to binary
compiler. There are several for the arm chip,
but there are none for the Saturn. But they are
not hard to write, merely tedious. The technology
has been used to bring many old programs from the
mainframe world that no longer have source code.
That happens more than you'd think - many of the
old mainframe programs were left as binary orphans
when the companies that wrote them ceased operation.
Despite the fact that many of these companies
supposedly had escrowed the source, often the
escrowed version was obsolete with respect to
the actual binary in use - or wasn't there at
all.
--
.-. .-. .---. .---. .-..-.|Experts in Linux: www.WildOpenSource.com
| |__ / | \| |-< | |-< > / |"Making the bazaar more commonplace"
`----'`-^-'`-'`-'`-'`-' `-' |Check out my new novel: "Cloud Realm" at:
home:www.smith-house.org:8000|<-this url + /books/list.html
Didier
> I'm not sure what you mean; all UserRPL commands written in
> "native ARM code" with no SysRPL or assembly language code in
> them?
>
increase the general speed... For example the time of computation in
difficult numerical integration...
Veli-Pekka Nousiainen
> Didier wrote:
>> ... in native ARM code ? Or is it a stupid idea...
>
> No. What is needed is a good binary to binary
> compiler. There are several for the arm chip,
> but there are none for the Saturn. But they are
> not hard to write, merely tedious.
Yesssh!
I vote for this!
Veli-Pekka Nousiainen
The "best" solution is using RPL2 compiled C to ARM CPU
and Linux to add the Bernard Parisse's Xiac/CAS-system
Large Video or small mini-Laptop Lion-battery
256MB of DRAM, 256MB of Flash
noth SDIO & CF card palces, etc...
Sounds a lot like Qonos...
Steen Schmidt
> I mean a new calc without the emulation of Saturn layer... With
> intent To increase the general speed... For example the time of
> computation in difficult numerical integration...
We could get there eventually with the current 49G+ - the more people
that chip in, the sooner.
I'm currently stuck at a very boring phase (integer
division/factorization & prime determination on a custom "zint" struct).
I hope the HPGCC team will feel enough support so that v3.0 eventually
will be released with (hopefully) the ability to patch the ROM.
Currently I have feedback from one (1) person who *might* have tried my
ExtraFunc C-lib. That's not too encouraging.
Regards
Steen
Veli-Pekka Nousiainen
X
> Currently I have feedback from one (1) person who *might* have tried
> my ExtraFunc C-lib. That's not too encouraging.
It's the best thing since sliced break
Could you package with it an "install.exe"
which would check the needed Toolbox lib (and install it)
plus do the FIXed STOrage operation
and finally ask for reboot yes/no (for auto attach)
Thanks!
Veli-Pekka
PS:
Promote the new version!
Claudio Lapilli
Steen Schmidt wrote:
> I hope the HPGCC team will feel enough support so that v3.0 eventually
> will be released with (hopefully) the ability to patch the ROM.
Just curious, what do you need/want patched in ROM?
Regarding "feeling support", at this point we don't care anymore, we'll
keep doing it as long as we have fun with hpgcc and we have free time
to work on it. For now... you don't need hope, just wait and see
because we'll be back (not very soon though).
>
> Currently I have feedback from one (1) person who *might* have tried my
> ExtraFunc C-lib. That's not too encouraging.
I know that feeling...
Claudio
Jean-Yves Avenard
> I mean a new calc without the emulation of Saturn layer... With intent To
> increase the general speed... For example the time of computation in
> difficult numerical integration...
Problem in doing so is that you will loose backward compatibility with
current and earlier model.
And you will start with a pool of existing 3rd parties software = 0
JY
Veli-Pekka Nousiainen
Yes - but keep the UserRPL compatibility
and naturally C-language as the PC platform
possibly even in the PDA-calc using Linux
The needed distro could be in a CF or SD(IO) or USB-stick
John H Meyers
> I mean a new calc without the emulation of Saturn layer.
To preserve the value of all existing software, which ranges
from UserRPL to SysRPL to ML to everything which comes in ROM,
it might be useful to concentrate on any specific internal functions
which are all of: time-consuming, frequently used and valuable.
I noticed that some of the CAS multiplied the original execution time
of common functions like ISOL by a factor of 16; if the CAS is still
perceived as a slow thing (and limited by memory), that might be
one area to work on, as well as operations on large matrices,
numerical integration, and whatever else is most time consuming,
rather than things which already give quite satisfactorily
good response times now, for which cutting those times to a millisecond
would add no value.
Otherwise, design an entirely new product from the ground up,
to better use the capability of all new technology.
[r->] [OFF]
John H Meyers
> What is needed is a good binary to binary compiler.
Would these bloat the original code, especially for
so unusual a "source" processor as Saturn?
By the time you get a UMPC with Emu48 in it,
you can probably blow away the HP49G+/50 speed anyway,
and have a general-purpose computer left over
to use for something else as well.
[r->] [OFF]
Ingo Blank
Hi Steen,
<...>
> I'm currently stuck at a very boring phase (integer
> division/factorization & prime determination on a custom "zint" struct).
Have you ever looked at the multi-precision decimal library
(libdecnumber.a), provided with HP-GCC 2.0?
Maybe it's worth to switch to that in the long run.
I myself have written some routines - mainly number theoretical stuff
like gcd(),invmod(),expmod(), Fermat Test, Rabin-Miller etc. -
with it, and it performs rather nicely. The main advantage IMO is, that
it is *very* mature code. See
http://www2.hursley.ibm.com/decimal/decnumber.html for documentation.
> I hope the HPGCC team will feel enough support so that v3.0 eventually
> will be released with (hopefully) the ability to patch the ROM.
Well, as Claudio stated before, we don't care no more about support.
As long as we ourselves have fun, and see folks like you and Tim
doing great things with it, we feel alright.
> Currently I have feedback from one (1) person who *might* have tried my
> ExtraFunc C-lib. That's not too encouraging.
I have personally no use for the extra functions, but I installed the
lib anyway. For me it's the proof of concept, that high performance ARM
code integrates seamlessly into the familiar calculator environment,
when it's done correctly and clean.
And don't worry, Claudio and I care for your work, so your active
community might be as big as at least 3 people ... :-)
Cheers,
Ingo
James M. Prange
>> I'm not sure what you mean; all UserRPL commands written in
>> "native ARM code" with no SysRPL or assembly language code in
>> them?
>>
> I mean a new calc without the emulation of Saturn layer...
Which language(s) would you use?
It seems to me that UserRPL is the ideal "ordinary user" language
for a calculator; I certainly wouldn't want to discard that.
Would you discard SysRPL? It seems to me that it's a very
intuitive language, and I'd hate to see it go.
Or just discard Saturn assembly language? The hardware Saturn used
on the 48 series does have some rather annoying limitations, but
note that quite a few of them have been removed from the emulated
"Saturn+" implemented in the 49g+, and several new instructions
have been added. See:
http://www.hpcalc.org/search.php?query=New+Saturn+Opcodes
It seems to me that everything already written for RPL calculators
would no longer work, at least as compiled objects; possibly
things could be recompiled from source code, but I expect that
the languages would be so different as to make it easier to pretty
much start from scratch, possibly reusing the general algorithms,
but rewriting all of the code.
> With intent To
> increase the general speed... For example the time of computation in
> difficult numerical integration...
It seems to me that with the current 49g+ emulated Saturn+,
with its added instructions, it may well be possible to speed up
selected operations considerably. Other than that, you also have
access to the underlying ARM processor; for example, with HP-GCC.
To me, this seems the best way forward; keep what we already have,
improving it where there seems a real need for improvement, and
adding new operations that would be useful.
--
Regards,
James
Steen Schmidt
Hi Ingo.
> Have you ever looked at the multi-precision decimal library
> (libdecnumber.a), provided with HP-GCC 2.0? Maybe it's worth to
> switch to that in the long run. I myself have written some routines
> - mainly number theoretical stuff like gcd(),invmod(),expmod(),
> Fermat Test, Rabin-Miller etc. - with it, and it performs rather
> nicely. The main advantage IMO is, that it is very mature code. See
> http://www2.hursley.ibm.com/decimal/decnumber.html for documentation.
Oh, the lengths I go to to proove my own stupidity...
That seems so close to what I'm currently trying to implement :-/ I saw
the decNumber lib mentioned in the HPGCC 2.0 distribution, but thought
"dec" != integers, hence not for my use. The first 10 lines of the doc
proved this to be wrong. I'll have a deeper look at it. Thanks.
> And don't worry, Claudio and I care for your work, so your active
> community might be as big as at least 3 people ... :-)
Hey that's great :-) Almost a user base explosion if you look at it the
right way ;-) I'll have a gander at the decNumber lib and see if I can
come up with something useful.
Regards
Steen
Steen Schmidt
> It's the best thing since sliced break
A sliced break - that's what I performed a couple of years ago on my
motorcycle ;-)
> Could you package with it an "install.exe"
That might be a good idea. I'll see if I can fit that into another
release.
Cheers,
Steen
Steen Schmidt
> Just curious, what do you need/want patched in ROM?
Along the way it would be nice to install a lib, and suddenly stuff
that took a long time before were a hundred times faster now - stuff
like solving, integration, plotting and maybe some of the most time
consuming integer tasks (division, square root etc).
This could be accomplished by a lib autoconfiguring itself at warmstart
with hooks into the ROM, to divert system calls into itself instead of
into the ROM. Maybe by using a small jump table in RAM, if the jumps
won't fit instead of the code it replaces.
> Regarding "feeling support", at this point we don't care anymore,
> we'll keep doing it as long as we have fun with hpgcc and we have
> free time to work on it. For now... you don't need hope, just wait
> and see because we'll be back (not very soon though).
Ok - I'll look forward to see what you are planning on. Until now HPGCC
has been amazing. I'm surprised there aren't a hundred people using and
discussing it here on c.s.hp48...
God speed,
Steen
Larry Smith
> On Mon, 19 Jun 2006 13:36:15 -0500:
>
>> What is needed is a good binary to binary compiler.
>
> Would these bloat the original code, especially for
> so unusual a "source" processor as Saturn?
That, I could not say. I am not intimately
familiar with the quirks of either processor.
Personally, I like the RPL/2 suggestion...
Larry Smith
> Veli-Pekka Nousiainen wrote:
>
>> It's the best thing since sliced break
>
> A sliced break - that's what I performed a couple of years ago on my
> motorcycle ;-)
Must've been painful... =:O
Didier
>
> Which language(s) would you use?
>
> It seems to me that UserRPL is the ideal "ordinary user" language
> for a calculator; I certainly wouldn't want to discard that.
>
> Would you discard SysRPL? It seems to me that it's a very
> intuitive language, and I'd hate to see it go.
>
science... In my mind I imagine a calc with the same high level language
(UserRPL and SysRPL) but without the saturn emulation...
John H Meyers
> don't worry, Claudio and I care for your work, so your active
> community might be as big as at least 3 people ... :-)
XC (a trivial project of mine which eliminates both mode changes
and forced variable deletions from CAS commands) also has
exactly three known users, so when it comes to free products,
of course we should always make things for ourselves,
and not worry about the market.
[r->] [OFF]
John H Meyers
> In my mind I imagine a calc with the same high level language
> (UserRPL and SysRPL) but without the saturn emulation...
On the binary level, even the choice of "prolog" words for various
RPL objects is intimately bound to the processor itself,
for these words represent both addresses and executable instructions
at the same time; it might be necessary to construct an entirely
different style of RPL interpreter to accomplish the same thing with
other processors, sacrificing the original interpreter efficiency
for a less processor-dependent system, now that much faster
(yet inexpensive) processors exist.
For deeper insight into the fundamental nature of HP's RPL,
and how it was designed in intimate correlation with a processor,
see http://www.hpcalc.org/details.php?id=1743
http://www.hpcalc.org/hp48/docs/programming/rplman.zip
"It is fundamental to RPL that objects can be executed
directly or indirectly with equivalent results.
This means that an object can be represented anywhere
by a pointer to the object as well as by the object itself."
The way in which very many "supported entry points"
are packed into a compact table (where every entry
jumps to the same address "11111") is also pretty fascinating:
http://groups.google.com/groups?as_q=11111&as_ugroup=comp.sys.hp48
[r->] [OFF]
Greg M.
I hope I'm on that list!
I used it just a couple days ago to make a program which needed to return a
complex variable in real mode. While I could have messed with
storing/recalling flags, that just isn't necessary when you can use
something as slick as XC.
Ah yes, and I've got a nice menu with some of the more annoying CAS
functions wrapped in XC.
Perhaps you need to release something buggy and only half useful... That
would probably elicit far more responses than perfection. ;)
I'm also betting there are plenty of lurkers who never post to the NG, yet
use programs like these.
Greg
Virgil
I hope I am being counted among them, as I use it all the time.
bokubob
>I hope I'm on that list
Virgil wrote:
> I hope I am being counted among them, as I use it all the time.
I hope I'm on that list too, I use it every day.
-Jonathan
John H Meyers
That's positively astounding --
now there are *five* known users of XC
(or maybe six, since I forgot that I've used it myself :)
Just want to be sure you all know, then,
that hpcalc.org has version 3 of XC
(now pure SysRPL, and bundled with a personal menu-maker
that gives the CUSTOM menu function something to do :)
XC makes CAS commands forget about mode changes
and removes conflicts with existing variables:
http://www.hpcalc.org/details.php?id=5493
http://www.hpcalc.org/hp49/math/symbolic/xc49v03.zip
[r->] [OFF]
Veli-Pekka Nousiainen
> Steen Schmidt wrote:
>> Veli-Pekka Nousiainen wrote:
>>
>>> It's the best thing since sliced break
>>
>> A sliced break - that's what I performed a couple of years ago on my
>> motorcycle ;-)
>
> Must've been painful... =:O
Last summer 3rd August a cager got me => sliced break
:-) or ...rather :-(
I just bought summer trousers - the last item missing
The cager's insurance covered just about everything
Veli-Pekka Nousiainen
I know I'm counted.... :-D
Veli-Pekka Nousiainen
> Didier wrote:
>>> I'm not sure what you mean; all UserRPL commands written in
>>> "native ARM code" with no SysRPL or assembly language code in
>>> them?
>>>
>> I mean a new calc without the emulation of Saturn layer...
>
> Which language(s) would you use?
>
> It seems to me that UserRPL is the ideal "ordinary user" language
> for a calculator; I certainly wouldn't want to discard that.
>
> Would you discard SysRPL? It seems to me that it's a very
> intuitive language, and I'd hate to see it go.
SysRPL must go!
HPGCC proves that you can do it all in C
and naturally user C the UserRPL only
DItch the Bitch and head for Qonos II
John H Meyers
> SysRPL must go!
> HPGCC proves that you can do it all in C
You can "do it all" with a "Turing machine," too,
just as you could have dug the Panama Canal with a spoon :)
"Back to abaci," say I.
[r->] [OFF]