Prev: Savage Benchmark on hp50g ??
Next: Odered HP50G from Sams Club
From: Harout Hedeshian on 23 Jul 2006 04:20
I was rummaging around comp.sys.hp48 to see if there were any
discussions on running linux on the ARM calculators. It seems that the
biggest problem is a lack of [enough] RAM. So I got to thinking: why
(other than "it's cool") would I or anyone else want to run linux on a
calculator? A calculator is a calculator, not a PDA, IMO. So instead,
I came up with a list of 'features' I would want in a calculator OS,
all of which I will discuss. With the advent of HPGCC, I got to
thinking, would anyone be up to writing an O/S OS for the HP-ARM
calculators?


----------
))Why an open source os? Who cares?
I am really into this open source thing. Whether it be BSD or GPL
(LGPL), I think being open source has it's advantages. It's going to be
a while before we see a fully ARM os from HP, and I think there are
things we could use in the calc that would take years for HP to
implement because of porting issues. So, I am writing this 'guideline'
for some sort of an OS that would run on HP calcs.

))Why HP calcs and not TI?
I don't want to toss out RPN, in fact the OS would be pretty much RPN
only. RPN is associated with the HP calcs and not TI. Also, HP's calcs
use the more powerful ARM chip. The only disadvantage I can think of is
the low resolution screen. It's time we started seeing vga monochrome
or qvga color devices (the gameboy color had a color screen w/out a
backlight that worked VERY well in daylight without much power
consumption).
----------

==========
Features:

1. Written in C
2. Stack based RPN
3. Multitasking
4. SysRPL & UserRPL scripting
5. Fully object oriented
6. Networking support
7. Power management
8 & 9. Command line and Application management; filesystem
10. Command stack

1. Written in C
It's been discussed, argued, flamed, and desired time and again.
Principally, speed is the issue. If an open source OS were to be
written, it provides a code base and language familiar to a lot of
people, and more convenient to use than ASM.

2. Stack based RPN
There are plenty of non-RPN calcs out there that are pretty good. I've
seen O/S implementations of RPN, which honestly are 'not up to par'
IMHO.

3. Multitasking
This creates an architectural issue. Primarily the locking of the
stack. The issue is: do you have one stack that all apps use, or do you
give each app it's own stack (appointed by the OS)? If one app changes
the contents of the main stack, then the other app would get confused.
A proposed solution would be to have the main stack be strictly
userland. When an app is launched, it can request arcguments from the
stack wich the OS will handle removing it from the main stack and
"giving" it to the app's private stack. Then anything returned by the
app will be pushed back on to the main stack. This would require a
superb memory manager in to OS to handle multiple stacks. I'm thinking
that the best solution to this would be to have a doubly-linked-list of
pointers to stacks which are made of a linearly-linked-list of pointers
to stack objects. This way memory could be accessed out-of-order. Then
you run into ram fragmentation issues. The OS could have a 'repack'
feature that would pack active objects to remove holes in the memory
too small to fit objects in.

4. SysRPL & UserRPL scripting
All calculators need some sort of run-time compile or interperit
scripting language. Since the OS would be stack based, UserRPL is
already a proven language, no need to reinvent the wheel. SysRPL would
be stricly for legacy application support. I was thinking along the
lines of VM (like Java) to allow SysRPL apps to be ported more easily
to the new platform. Something like this would undoubtedly be a
hurculanean task.

5. Fully object oriented
It allows for pretty neat coding. AFAIK SysRPL is not OO, and I know
UserRPL is not OO. I know you can push objects on to a stack, but I
don't know if the underlying existing os is. It would also be nice to
have a simple OO model for writing userland scripts.

6. Networking support
This is mostly wishful thinking. Even though you might be able to
support CF wifi, or the sort, there simply is not enough RAM in present
units to use it for networking. It would have to be a very stripped
down network stack possibly without support for TCP/IP (maybe UDP/IP?).

7. Power management
I would like to see a userspace governer controlling CPU speeds based
on activity to prolong battery life. There is noo need to be processing
73 million no-ops per second when idling.

8 & 9. Command line and Application management; filesystem
One of the biggest advantages to of an HP over a TI is that it has a
very crude command line (the stack) and the scripting language uses the
same commands. Now I'm not saying we should have a full blown csh or
bash, but a more functional shell would be nice. I also dislike the
libraries system currently in use.

I would suggest a modified UNIX/Linux file tree layout with something
like this (Use JFFS underneath)
r:read
w:write
c:create/delete

+++Flash+++
rw /etc (store calc config)
rwc /etc/apps (store app config) --OR-- /usr/local/appname/etc
r /bin (built in apps)
r /lib (system code base, app usable)
rwc /usr/bin (user writable, but by convention, only put symlinks)
rwc /usr/local/appname (actual application location)
rwc /usr/local/lib (application code base and shared libs)

+++RAM+++
rwc /var (variables)
rwc /tmp (app FS non-stack workspace ram)

++Virtual+++
rw /dev (access to ports and I/O. Potentially even drive the screen
this way (lockable)).

Much like MacOS, you could hide the underlying file tree from the user
using the normal GUI. Obvoiusly, this could share a good bit of code
from Linux. It doesn't need things like permissions or extended
attributes. You could *potentially* even implement something like this
with the existing os.

10. Command stack
Used for executing `undo` commands.
==========

Enough writing. I'm going to post this and go to bed. I could get in to
nitty gritty details about every single function, but I'm too lazy to
do that now at 2:15am. These are mostly of underlying paramount
importance.
I don't know... I guess I'm just dreaming. This is what it would be in
my own world. Keep in mind I'm only talking about the OS side of
things. One day I may post about mathematical apps that could be
integrated. Oh, and one more thing, integration with abs() MUST be
f
From: Harout Hedeshian on 23 Jul 2006 18:13
One more thing I forgot to add:
As part of the underlying OO design for the OS, it should use the
"blackbox" methodology. Most parts of the OS should be writted such
that "something goes in and something comes out". This way, major
changes can be made to the OS without rewriting programs. You can still
run Office 97 on a Windows XP box. For example, instead of having apps
deal with the stack's pointers and data structure directly, have it
talk to a 'stack module' which handles it. The stack implementation
could then be changed without rewriting the software (ie you decide to
use a fixed length array instead of a linked list for speed reasons,
etc). Also, this way you could potentially have multiple types of
stacks which an application can request based on it's needs. For
example: in Java you have your ArrayList class which implements the
List interface as well as LinkedList class which implements the List
interface. Both have the black box approach and you can interchange
both at will without any problems. But each has it's own implementation
and its advantages: ArrayList has instant access to data locations
while LinkedList needs to traverse the list. Linked list can append or
modify the list by moving pointers where ArrayList has to copy the
array data to a new array of the correct size and delete the old one.
You get the point.

From: Alain Mellan on 23 Jul 2006 19:41
Harout,

Take a look at www.openrpn.org and sourceforge.net/projects/openrpn.

-- alain.


From: Harout Hedeshian on 23 Jul 2006 21:25

Alain Mellan wrote:
> Harout,
>
> Take a look at www.openrpn.org and sourceforge.net/projects/openrpn.
>
> -- alain.

Tha's a very interesting project. I see they're planning to run it on
ecos, but that becomes a problem IMO:

"eCos is a single process, multiple thread operating environment. As
such, memory management is not required.... There is no notion of
separate address "spaces"... All threads share the same address space
and access capabilities."
--http://ecos.sourceware.org/fom/ecos?file=84

Correct me if I am wrong but making it fully multitasking would be
difficult. For example, if you want to plot something while there is a
different program collecting data over the serial port.

Also, they're using new hardware. I think, other than quality issues,
the HP hardware is just fine. There is no need to reinvent that wheel.
Also, I see from the forums that you were working on a retrofit of the
49g+? How's that comming along? Have you figured out how to get
something booted on it?

From: Jean-Yves Avenard on 24 Jul 2006 00:34
Harout Hedeshian wrote:

> Correct me if I am wrong but making it fully multitasking would be
> difficult. For example, if you want to plot something while there is a
> different program collecting data over the serial port.
You could still do this under eCos with no problem whatsoever.

eCos is a great RTOS...

JY
 | 
Pages: 1
Prev: Savage Benchmark on hp50g ??
Next: Odered HP50G from Sams Club