Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #10910

Re: A short history of the stages of development and status of RP's

Show all headers | View raw

Paul Rubin <no.email@nospam.invalid> wrote:

> Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net>
> > ... you guys are going to have to learn a lot about System Z if you're
> > going to keep banging on me about it.
> 
> You're asking the newsgroup for advice about solving a certain problem,

Uh where did you get that idea from, your crystal balls? ;-)

I asked if there was a standard for Forth that most Forthers agreed was
good. There my question stopped. You guys took it from there.

If I do this project I am sure I will be asking for help on Forth but so far
I haven't.

> so yes, we can probably be more helpful if we understand the problem
> better, thus the questions. ;-).  The problem itself is also sort of
> interesting.  From a contemporary programmers' viewpoint, this System Z
> thing sounds almost like an alien mothership landing, that on closer
> inspection is built with weird neolithic technology.  They built a
> stardrive out of THAT?  They certainly have access to modern Earth
> materials, so it's perplexing why they don't use it if they are still
> building the stuff.

Humor aside the design of everything from the architecture to the tools was
and is ahead of its time. It's very modern and offers more control over
workload and finer grained control of resources and performance and recovery
than any other common OS. And I get to use my favorite language all the time.

> >> Is an interpreter a key feature that you've decided on?
> > Maybe. Probably. Isn't an interpreter something every Forth should have?
> 
> It could be a cross-compiler, for example.  I'm not sure if that's what
> Rod meant.

That doesn't sound very attractive. This will be hosted on System
Z. Ultimately it will need to be compiled to be useful.

> 
> >> Is threaded code a key feature that you've decided on?
> > What does that mean, multithreaded? Or threaded as in Threaded Interpretive
> > Languages threaded.
> 
> Threaded interpretive language.  The alternatives would be bytecode,
> native code compilation, etc.  As a separate topic, there are
> multitasking extensions to Forth that are pretty simple, and might be
> useful to you if your host OS doesn't supply decent multitasking.

I guess I'll have the TIL implementation to begin with and for building the
system up. After that everything will be compiled to some extent. Native
compilation, not bytecode. An authorized VM would be truly weird. I have to
think about that one. The OS supports all the multitasking you could ever
want, just need to invoke the right services.

> 
> > I don't think so. Part of writing systems software is avoiding painting
> > yourself into environmental corners that all existing HLL have painted
> > themselves into. 
> 
> I'm still trying to understand what these corners are.  I'm imagining by
> "systems code" you're talking about writing low level device drivers
> where you have to pass a control block with a precise bit layout, using
> systems services that require data passed in specific machine registers,
> that sort of thing.

That but not only that and not even mostly that. You have to not depend on
system services that stop you from using other systems services. Existing
compilers don't have to deal with this so they can always use SVCs for
example. Systems software often has to do things that can't be done with
SVCs so if the code invokes the service in the wrong mode it will fail.
That's just one very simple case, there are dozens of others.

>  Forth might be useful for part of that, but you'll
> still probably need asm interface layers at the bottom level.

The whole point of this is to allow everything to be done natively in one
language (Forth). If there is one line of external assembler required then
it's a fail.

> 
> > I have to believe, looking back, it was a conscious decision not to
> > allow that...just like IBM never let PL/S, PL/AS, PL/X outside (except
> > as noted). They were afraid it would be too easy to write systems
> > software and compete with them,
> 
> That may have been the situation in the 1960's but I think these days,
> compiler technology is much more accessible, and also nobody(?) is
> really trying to compete with IBM on those mainframe systems.

That's not correct. I work for companies that write systems software for IBM
machines and it's a multi billion dollar a year business even now. IBM has
sued several of these companies and bought some of them out. There is a lot
at stake and a lot of competition. Everything is trade secrets and patents
and no edge is left unturned. IBM still wants to make money selling software
and they still want to keep all the advantage they have.

> I looked at the docs for BSL (Basic Systems Language, apparently an
> earlier name for PL/S) and it's a quite low level implementation
> language (I'd say mostly lower level than C), with PL/I syntax.  It lets
> you do stuff like manually allocate machine registers to variables ("put
> variable X in register 9"), use inline asm code freely, etc.  It also
> seems to handle bit-fields conveniently, e.g. you can declare a variable
> to be 13 bits wide.  All in all though, it looks archaic.

It should, it's from the 1960s. PL/AS, then PL/S, then PL/X have modernized
things. It's what most of the OS is written in now.

> That stuff today is usually written in C with some asm intrinsics or
> subroutines. 

Except for the fact that until very recently there was no C available on IBM
that could support the asm interface and the environmental requirements. Now you
can use mostly "C" but you'll be doing 90% of it in C's assembler syntax.
Nobody could suggest it's a good or even acceptable solution. It's ugly,
it's unreadable. But you can claim "you did it in C".

> It also occurs to me, I'm not sure what you don't like about C, but if
> it's lack of type and pointer safety compared with PL/S, then you might
> decide that Forth is worse rather than better.  Forth (like assembler)
> has no typechecking of any sort.

No, I write assembler and I don't need any of that stuff. Where I work C
doesn't have any reason to exist. I realize in other places it does.

> Maybe you really want something like Ada rather than Forth.

I don't think I could write an Ada compiler at all and it would have to
support system programming semantics (I know there is a systems programming
annex, and no, it does not allow you to write systems software on z) which
means a new syntax and again, any language anybody writes is going to need
to include a way to access all the system control blocks and services
natively because now they're 100% assembler/PL/X only. That's a project for
a comittee and a consortium, it's not something any one person can do. I
have heard of a couple of guys who might be able to write a compiler like
that but I am not one of them as far as I know. Anyway the Forth angle is
the extensibility. Ada is Ada. If you need to add stuff you either change
the language so it's not Ada or you have to call external code. In Forth you
can theoretically add words and stay within the Forth "way" and still do
whatever you need. At least that is what I'm thinking from what I have seen
so far.

> I've thought of Forth and Ada as sort of opposite approaches to getting
> away from the shortcomings of C.  Or, maybe some aspects of PL/S that C
> doesn't handle very well could embed conveniently into C++.

I guess you could look at it that way but I think Forth wasn't written as a
response to C because C wasn't very pervasive at the time Forth was designed.
Seems Chuck Moore just wasn't happy with anything available. And Ada I think
was a response to general chaos and lack of discipline more than a reaction
to C, it was also fairly early. And Ada is based on a PL/I or ALGOL syntax
and is for a different kind of programmer. C is a weird hybrid mutation.

I don't know if you could get C++ to do what PL/S does but I do know on z it
would involve several things. One you would have to disconnect the runtime and
replace it with your own. I don't know if this is possible or not. If IBM
offers the same option with their C++ as they do with C then it is already
available. Then you would have the same issues as in C, lack of
environmental support. If environmental support was also added to C++ at the
same time then it will be ok, if not then there is no way to do it. If all
that is ok so far then you still need to wrap huge amounts of code in the
C/assembler ugliness and make classes out of it. But I think the end result
wouldn't be very usable. 

> > I realize technically that's true but it seems so abusive to write
> > systems software in LISP. And it has to be something I don't despise
> > so..apologies to Paul, I know he is a Lisp fan, but it's not my
> > thing. In the end there is going to have to be a compiled version or
> > it won't be very useful.
> 
> Lisp is very often compiled, and OS's have been written in it.  Most
> serious Lisp systems include compilers

I am aware of that. I think some context was lost in what you quoted or
maybe I did a poor job of editing. I think my comment about wanting a
compiled version was an answer to something Rod had said that you didn't
quote.

> > Neither brainfuck nor Forth nor any existing language has the facilities
> > needed to write systems software on Z. The difference is you could probably
> > write Forth and extend it
> 
> Rather than writing your own Forth, maybe you should spend some evenings
> looking at Eforth, which is very easy to port to an assembly language
> target.

Again, this project is much much more than porting anything to an assembly
language target. If that's all it was it would be useless to me, and also
not interesting. All it would be is an application language and I would
still have to write a whole new runtime. The point is, can I write a systems
programming Forth for z and would I use it? Those are the questions I'm
thinking about. 
> 
> > can you tell me on Intel since you know it so well, how would you
> > switch from 32 bit to 64 bit mode and how you could change privilege
> > levels in brainfuck?
> 
> Pretty much the same way as in C, Forth, Ada, or anything else, I'd
> imagine.  You'd use the HLL to build up the necessary x86 data
> structures (page tables, segment register contents) in memory, then call
> a small assembly language routine that zaps your data into the
> appropriate machine registers.

Again unacceptable. I don't see the advantage in making things more
complicated. Today life is simple. I am looking for a pure single language
solution. When I write assembler I don't need anything else. The assembler
is super. When I write PL/X I don't need anything else. Anything else I
would be interested for this project has to be able to do everything. I
don't like mixed language projects and I don't need another, inferior
tool.

> The idea is to do what you can in the HLL for maintainability purposes,
> then call a minimal asm layer for the low level hardware specific parts.

I accept that most people hold this view but in my business we don't and
until now we haven't seen any use in HLL at all except for the UI where Rexx
was used and increasingly C, C++, and Java are used. The code we sell is
usually not algorithmic and we haven't found we would gain by using any
HLL. Some people might tend towards an HLL if one was available that could
support the environment but at this point there isn't anything but the newer
C and again it's ugly and probably harder than assembler. You really have to
want to make a point and be some kind of nutty C evangelist to use it for this.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: A short history of the stages of development and status of RP's For  interpreter. Nomen Nescio <nobody@dizum.com> - 2012-03-25 10:30 +0200
  Re: A short history of the stages of development and status of RP's For  interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-25 06:05 -0400
    Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-03-27 03:03 +0200
      Re: A short history of the stages of development and status of RP's "Elizabeth D. Rather" <erather@forth.com> - 2012-03-26 15:39 -1000
        Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-28 11:18 +0200
          Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 07:04 -0400
            Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-30 19:24 +0200
              Re: A short history of the stages of development and status of RP's Paul Rubin <no.email@nospam.invalid> - 2012-03-30 13:00 -0700
                Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-04-04 16:09 +0200
              Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 18:06 -0400
                Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-02 16:39 +0200
                Re: A short history of the stages of development and status of RP's Paul Rubin <no.email@nospam.invalid> - 2012-04-02 15:37 -0700
                Re: A short history of the stages of development and status of RP's BruceMcF <agila61@netscape.net> - 2012-04-02 16:59 -0700
                Re: A short history of the stages of development and status of RP's kenney@cix.compulink.co.uk - 2012-04-03 17:15 -0500
                Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-04 05:23 -0400
                Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-04-04 15:58 +0200
                Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-05 09:57 -0400
                Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-11 21:23 +0200
                Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-11 19:13 -0400
                Re: A short history of the stages of development and status of RP's jacko <jackokring@gmail.com> - 2012-04-11 18:22 -0700
                Re: A short history of the stages of development and status of RP's hwfwguy@gmail.com - 2012-04-13 09:37 -0700
                Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-05 11:21 +0200
    Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-27 13:08 +0200

csiph-web