Re: Forth as an operating system

On Nov 28, 4:51 pm, s...@xxxxxxxxxxxx wrote:
Foxchip has some *VERY* good points

Agreed, as do you...

I believe from this follows that Forth is a single task deployment
language/system for a small deeply embedded system ... I'm not convinced
that Forth is living up to its potential in that model, but traditionally
this has been Forth's *fate*. That could change.

I wish I could have said that as well as you have :)

Cooperative multitasking IMHO is an historical artifact of that being the
simplest implementation of a tasker in fig-Forth, given the architecture.
Nothing in the language itself prevents the development of a full fledged,
protected mode, interrupt enabled, device supporting, multi tasking
executive or even hard real time services.

*nods* Preemptive multitasking is a must IMO.

We don't need "something like unix", we have that, and more. With the
proliferation of embedded devices like pda/cell/xberry, what we *COULD*
use is a small footprint simple OS, with a plug in device driver model
which supports a facile development environment and possibly a GUI dev
system built upon a frame buffer model.

Add the facility for 3rd party code to be inserted into a deployed
system
and you are fairly close to a general purpose OS.

A *LAUDABLE* goal, IMHO!!! But I think that X86 is *ABSOLUTELY*
ideal ... read on.

If you develop it, you could call it *Werty* 8-)

I'm not sure that werty (assuming he's not robotic and therefore
devoid of emotion) would like that. I had considered 7OS (fifth is
taken, sixth doesn't sound right, seven is next) but then Microsoft
stole my idea ;)

Having just visited ForthOS, and having had a very positive experience, I
might suggest holding off on the underlying Forth, as that has been done
to death.

Good advice, sometimes I feel the urge to code but I should really
take
the time to examine what exists.

Instead, create a proof of concept by pick a working reference
platform (eg: ForthOS on QEMU 'frinstance) which will give you a running
head start, as the Forth is already in place, the devices are well known,
the BIOS is available in source form, and it allows you to focus upon *THE
PROBLEM*.

Due to the problems I perceive with x86 I was planning the GP2X as
my reference system. Perhaps I'm wrong, maybe x86 isn't as problematic
as I think... but what about the single stack? That's gonna hit
performance
hard?

<various helpful suggestions snipped>

Thanks, I will give this though. I suppose any performance
considerations
on x86 don't seem as important for a portable system.

Having seen the effort thrown at a foonix in the past and the results
achieved I think very few are interested. Forth OS tend to be as
'complete' as they need to be and if Linux defines 'complete' then
people have Linux. Linux isn't Forth but can host Forth, it isn't
an all Forth system. The two ideas of embedding OS as needed for
cooperative programs and creating a monolithic OS for all languages
and resolving the problems of hostile programs are just so different.

I believe that the above paragraph is *GOOD* advice. We don't need
another foonix, but Forth has not yet achieved its potential, which
is a pity.

Agreed, it is that potential I would like to see realized. I'm really
not the person for the job, but if no one else is willing I feel I
have to try.

Don't re-invent what has already been done, but rather figure out what
would make a small (tiny?) footprint, multitasking, device-friendly,
end-user friendly embedded OS which you might run on a phone, microwave
oven, pda, set top box, automobile,

I'm more interested in the desktop or more powerful embedded devices
(phones, pdas etc.). Of course with a well designed system it could be
scaled in either direction.

It does *NOT* have to be big.
It does *NOT* have to be posix.
It does *NOT* have to support C or any other language.
It probably *DOES* have to support some sort of GUI interface API.
It *DOES* have to be portable.
It *DOES* have to run like the wind.
It *DOES* have to look nice (sigh).
It *SHOULD* encourage vendors/developers to provide new device
support both for peripherals and processors by way of its streamlined
design and elegance.

Yes, I agree with all that.

A clean slate design based upon Forth's strengths and modern hardware.
What could be simpler?

Precisely!

Regards, George
.

Relevant Pages

  • Re: various objects in my VB6 project - Calling IUnknown
    ... legacy support for EXEs is an order of scale beyond ... "Language Stability" enjoyably employs structure. ... But I'm not black and white on the matter of migration changes. ...
    (microsoft.public.vb.general.discussion)
  • Re: Architectural support for programming languages
    ... microarchitectural support in processors for operating systems to make ... The language used will match the programs, ... were adding architectural features to take their share of new market ... and run them under and OS written in C and on architecture with all ...
    (comp.arch)
  • Re: Forth as an operating system
    ... hostile, buggy, or badly written and protection is essential. ... Nothing in the language itself prevents the development of a full fledged, protected mode, interrupt enabled, device supporting, multi tasking executive or even hard real time services. ... The two ideas of embedding OS as needed for ...
    (comp.lang.forth)
  • Re: how is Haskell not robust?
    ... Haskell has not reached critical mass. ... have a thousand packages but still poor support for mainstream package ... If anyone would make money with the language or a compiler ...
    (comp.lang.functional)
  • Re: Why should I eschew prototype.js?
    ... Microsoft drives this market, whether people admit it or not. ... out next week and proclaimed "The only markup language we will support ... Furthermore, if any other attributes are present, IE will ignore the script block. ...
    (comp.lang.javascript)