Re: GraspForth ... a new forth written in C
Elizabeth D Rather
news:9a37459a.04093...@posting.google.com...
> Hi All,
>
> I'm back in the Forth world again, after a 'too-long' absence.
>
> In my work I have been involved with many micro-processor projects
> which begged a version of Forth to speed development. However, I have
> been continually frustrated in finding suitable forth's to run on
> them. I would normally have to port an assembly version or put up with
> a large Forth written in C. So in the true nature of a Forth
> programmer, I have written my own "portable" Forth.
I'm curious, what platforms were you unable to find a suitable Forth for?
> My goals for this forth are:
>
> 1. Small, kernel < 25Kb for a 32 bit machine. ( ~ 220 words in kernel)
> (including headers)
Hmm, our 68K kernel is 7K without heads, and 12K with. Of course, the main
development tools remain on the host, since we support an umbilical
cross-development environment. But it's just as interactive as a
target-resident Forth, and a lot more powerful.
> 2. Fast, not to be 'too much' slower than eForth.
SwiftX generates optimized machine code, and is very significantly faster
than eForth.
> 3. Portable .. all that should be changed is the memory map, KEY/EMIT
> functions and specify the ENDIAN'ness
That much information hiding ends up leaving you with a pretty inefficient
target, and I'm not sure that C compilers for various target are so
compatible that retargeting is really effortless. We do put a lot of effort
into adapting the target model to each processor (selecting registers
appropriately, etc.), but once a processor family is done all we need to do
for a new configuration is adjust the memory map and possibly I/O register
designations. Drivers may change, but we minimize that where possible by
using on-chip I/O.
However, 75% of our source files are completely high-level and portable
across all targets (both 16-bit and 32-bit).
> 4. Full Interpreter on Target. (i.e NOT umbilical) I want to talk
> to/download to my target from anything that supports a serial port.
Well, we support a target-resident interpreter with basic compiling
capabilities. That is useful for things like field diagnostics and
configuration changes, but we prefer the umbilical connection for serious
development, because it is faster than downloading the source for a complex
project over a serial port to a slow target-resident compiler which can only
generate slow code.
On the whole, it sounds like a fun project, but the result isn't really
appropriate for a serious project.
Cheers,
Elizabeth
Guy Macon
ebike <eb...@paradise.net.nz> says...
>Small, kernel < 25Kb for a 32 bit machine. ( ~ 220 words in kernel)
>(including headers)
...
>Do you want a small portable forth-in-C, what interest is out
>there?
In my opinion, you are shooting for the wrong target. There are
other Forths that have kernels that are one half to one third of
your 25KB, and they are mature, blazingly fast, and well-debugged.
Your is a "me too" effort.
What I would like to see is a Forth that is optimized for absolute
minimum not-written-in forth content, with *no* consideration given
to speed issues. Barbie dolls don't need a fast Forth. Simple
programs that run on multi-GHz machines don't need a fast Forth.
Get your Kernel <4KB and it will fit in the L1 cache of just about
every cached processor out there. Comment that <4K really well
and it will be really easy to rewrite it for another processor.
Do the rest of the system right and the kernel and some I/O code
written in Forth are all you need to change to port to another
system.
Stephen Pelc
>In my work I have been involved with many micro-processor projects
>which begged a version of Forth to speed development. However, I have
>been continually frustrated in finding suitable forth's to run on
>them.
Given the number of CPUs supported by MPE, Forth Inc and others,
I can only assume that you mean free-of-cost Forths.
There are any number of portable Forths in C available free
or for money. Why reinvent the wheel?
Stephen
--
Stephen Pelc, steph...@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Gustavo Cordova Avila
> ebike <eb...@paradise.net.nz> says...
>
> >Small, kernel < 25Kb for a 32 bit machine. ( ~ 220 words in kernel)
> >(including headers)
>
> ...
>
> >Do you want a small portable forth-in-C, what interest is out
> >there?
>
> In my opinion, you are shooting for the wrong target. There are
> other Forths that have kernels that are one half to one third of
> your 25KB, and they are mature, blazingly fast, and well-debugged.
> Your is a "me too" effort.
>
I concur completely, but...
(always one, everywhere).
I believe that creating "me-too" variants is what helps things
evolve, and also increase one's knowledge and wisdom, so ebike,
don't feel too down, you're going to learn quite a lot by building
you're own forth variant.
If you feel the need for experimentation, go ahead and don't
let critical comments dissuade you; but for professional tools,
go to professional tool creators :-)
Good luck with your experiment, keep us posted please.
-gustavo
Brad Eckert
>
> My questions for this group are:
> 1. Do you want a small portable forth-in-C, what interest is out
> there?
> 2. I will need volunteers for the testing phase (either on a Linux
> machine /or Windows-Cygwin/ and/or a 32 bit uP)
>
Do you mean an ANS Forth? We already have lots of those.
Have a look at colorForth (www.colorforth.com) for some different
ideas. You don't have to implement colorForth exactly the same way as
Chuck. For example, he uses preparsed, huffman coded names. No need to
do that.
The compiler lays down machine code. You might want to use a different
register model that allows Windows (or Linux) to relocate your code.
I don't know if calling your compiled code from the C console can be
done portably, but at least it will be almost portable.
Brad
Peter Lawrence
.
.
.
> What I would like to see is a Forth that is optimized for absolute
> minimum not-written-in forth content, with *no* consideration given
> to speed issues.
I'd have said eforth was already doing that by having a minimal amount of
machine code, with the secondaries needed to implement the text/outer
interpreter built into the assembler source as assembler data. But you must
know about that so you must mean something else.
Do you mean a minimal amount of high level material to implement the
text/outer interpreter, so that you can have a minimal sized package before
you have something that can run and bring in its own extensions? If so, it
depends what you classify as Forth.
The other day I described a simple batch source interface for the Forth
virtual machine that allows you to extend it. That works by compiling
everything it recognises into an anonymous secondary, terminating it with
tail recursion as soon as it gets something new (returns are handled by a
predefined conditional return word, the only explicit control flow
construct). The current secondary gets given the new name and keeps scanning.
When the input ends the last secondary is still anonymous and gets run; it
can do the job of saving the memory image as an executable, or go straight
into a fuller language, or some application on a compile and go principle.
This proto-compiler can use a simplified fixed format proto-source and
dictionary, too (e.g. anything with a preceding space is ignored so that only
beginnings of lines are used, allowing comments).
I wouldn't classify that as Forth myself, but it does let you run something
free standing that can boot into a fuller language, and it should make for a
much smaller executable to get things started. I think a clever pre-processor
could cascade a subset of Forth straight into this too, which is cheating by
getting back towards the spirit of the umbilical approach.
I would appreciate feedback on this - I am using something like this in my
recent thought experiments on Furphy
(http://member.netlink.com.au/~peterl/furphy.html, but I haven't updated that
lately). PML.
--
GST+NPT=JOBS
I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.
See http://member.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.
Guy Macon
Peter Lawrence <pet...@netlink.com.au> says...
>
>Guy Macon wrote:
>
>> What I would like to see is a Forth that is optimized for absolute
>> to speed issues.
>
>I'd have said eforth was already doing that
I had never looked into eforth before reading your post.
Let's do a search...
http://www.baymoon.com/~bimu/forth/
THE GOOD NEWS:
"eForth allows me to make a complete Forth system with about
30 very simple machine code routines."
THE BAD NEWS:
"eForth should be considered a model, not a working Forth
development system."
Ed Beroset
For what it's worth, an updated version of eForth is hForth. I like it
better and have used it for a couple of projects.
Ed
Guy Macon
Ed Beroset <ber...@mindspring.com> says...
>>>Guy Macon wrote:
>>>
>>>
>>>>What I would like to see is a Forth that is optimized for absolute
>>>>minimum not-written-in-Forth content, with *no* consideration given
>>>>to speed issues.
>For what it's worth, an updated version of eForth is hForth. I like it
>better and have used it for a couple of projects.
(...Does a search...)
http://www.taygeta.com/hforth.html
Z80:
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/dos/hForth/hf86v099.txt
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/dos/hForth/hf86v099.zip
8086:
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/dos/hForth/hfz80v99.txt
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/dos/hForth/hfz80v99.zip
StrongARM:
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/dos/hForth/hf-arm.txt
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/dos/hForth/hf-arm.tar.gz
Very nice, at least from looking at these web pages. I will give it a try.
So, is *this* the answer if someone wants a bare minimum of Forth
words written in assembly language, with everything else consisting
of Forth words built upon Forth words? Does *this* one give you
a system where you can replace the few assembly-language-based words
(and possibly a few words defining I/O) and be up and running on a new
processor? Or is there yet another Forth that is even better at meeting
these needs? Enquiring minds want to know! :)
--
Guy Macon <http://www.guymacon.com>
ebike
> or for money. Why reinvent the wheel?
>
Simply because the "wheel" happens to be a wagon-wheel and I'm
building a fast racing bike!
The free Forth's-in-C are suitable for some large projects ie gForth
but not snall embedded projects. Even pForth cannot be ROM'ed, they
all fail in some respect. .... so I'm inventing a "better" wheel.
ebike
I see you still have not suitable advertising medium for your products
;-)
.... maybe a new newsgroup called comp.lang.forth.free needs to be
started ... an add-free zone ... my post was concerning "free" Forth's
in C, not commercial ones.
That aside, you seem to have missed the whole point of my post. In
respect to "tethered" forth's for example. I don't want one. The
reason is simple, I don't want to carry around the development system
in the field. For example, I want to be able to
configure/program/modify my products in the field with a PDA for
example .. or a laptop .. or the kitchen sink, anything with a serial
port. I don't want to drag around a development environment, if I
wanted that I'd write using C tools. Also, your argument about slow
compile times and execution doesn't wash either, Forth applications
"are" small and compile in a couple of seconds, even for my most
ambitious projects and run-time is fast-enough for anything I care to
do,including some demanding real-time stuff.
> On the whole, it sounds like a fun project, but the result isn't really
> appropriate for a serious project.
>
It is this sort of snide patronizing comment that makes me want a want
to push for a UseGroup that bans product Vendors. I have used "Free"
Forth's in thousands of "serious" products and in "mission critical"
situations. Get off your high horse Elizabeth, there are many
succesful people out there using "Free" Forths in useful products ...
commercial Forth's are "not" the only solution.
ebike
> evolve, and also increase one's knowledge and wisdom, so ebike,
> don't feel too down, you're going to learn quite a lot by building
> you're own forth variant.
>
> If you feel the need for experimentation, go ahead and don't
> let critical comments dissuade you; but for professional tools,
> go to professional tool creators :-)
>
> Good luck with your experiment, keep us posted please.
>
> -gustavo
Thanks for your kind comments Gustavo, I'ts good to have some support
instead of criticism ... I will keep you posted.
ebike
> other Forths that have kernels that are one half to one third of
> your 25KB, and they are mature, blazingly fast, and well-debugged.
> Your is a "me too" effort.
The "other" Forth's are not "free" Forths. The Free Forths-in-C are
typically too big for embedded applications i.e gForth, too slow or
not ROM'able .. as in pForth .. or the others are not standard enough
for my liking.
Put your money where your mouth is my friend, please name these
amazing Forths. Keep in mind that they must be Free and Written in C.
> What I would like to see is a Forth that is optimized for absolute
> minimum not-written-in forth content, with *no* consideration given
> to speed issues. Barbie dolls don't need a fast Forth. Simple
> programs that run on multi-GHz machines don't need a fast Forth.
> Get your Kernel <4KB and it will fit in the L1 cache of just about
> every cached processor out there. Comment that <4K really well
> and it will be really easy to rewrite it for another processor.
> Do the rest of the system right and the kernel and some I/O code
> written in Forth are all you need to change to port to another
> system.
If you are putting in uP's with L1 cach'es into Barbie Dolls, you have
a real problem my friend! I would you an MSP420 from TI for that with
256 bytes of ram and 16k FLASH... but that's just me.
You miss the point. I have been there, done that, in respect to
porting Forth's for new uP's .. ie eForth. It was fun, but very time
consuming .. and eForth cannot be ported with GCC (AS) AS cannot have
look-ahead ORG statements. Of the Free Forth's eForth(or hForth) is
the best assembly based solution *if* you have the commercial
assembler for that micro .. and you have time for the port.
I do "not" have the time to port to all the uP's I want to use, hence
this work I am putting in now for a portable solution.
Maybe next time you post, you could offer some encoragement, instead
of pulling down a valid solution to a problem. Helpful suggestions are
most welcome.
ebike
>
> THE GOOD NEWS:
>
> "eForth allows me to make a complete Forth system with about
> 30 very simple machine code routines."
>
> THE BAD NEWS:
>
> "eForth should be considered a model, not a working Forth
> development system."
I beg to differ. I have used eForth in many Commercial products
including my own port to the H8/532 uP.
Guy Macon
ebike <eb...@paradise.net.nz> says...
>> "eForth should be considered a model, not a working Forth
>> development system."
>
>I beg to differ. I have used eForth in many Commercial products
>including my own port to the H8/532 uP.
You beg to differ with the eForth documentation? YYRRW.
Guy Macon
ebike <eb...@paradise.net.nz> says...
>Put your money where your mouth is my friend,
>...
>snide patronizing comment
>...
>you have a real problem my friend!
>...
>Get off your high horse
>...
>Maybe next time you post
Lose the attitude or be killfiled.
don groves
<http://www.guymacon.com> wrote...
Pot calling the kettle black?
There have been some high-handed comments directed his way.
I think Elizabeth momentarily forgot her roots when she said
ebike's way is inappropriate for serious projects.
--
dg (domain=ccwebster)
Jerry Avins
Defensiveness seems to have gotten the better of you. (If there's a more
fundamental reason for your behaving like a jerk, I'd like to know it.)
If you can "configure/program/modify [your] products in the field with a
PDA for example .. or a laptop", you can run a development system on the
PDA or laptop. Clearly you know that, yet you pretend not to. Why?
Jerry
--
... they proceeded on the sound principle that the magnitude of a lie
always contains a certain factor of credibility, ... and that therefor
... they more easily fall victim to a big lie than to a little one ...
A. H.
———————————————————————————————————————————————————————————————————————
Jerry Avins
We all like to see innovation. Innovation is more useful when its worth
is properly evaluated.
Bill Muench
Guy Macon <http://www.guymacon.com> wrote:
>
>ebike <eb...@paradise.net.nz> says...
>>>"eForth should be considered a model, not a working Forth
>>>development system."
>>
>>I beg to differ. I have used eForth in many Commercial products
>>including my own port to the H8/532 uP.
ebike, you may wish to consider a note I have included with
eForth:
Copyright Bill Muench All rights reserved.
Permission is granted for non-commercial use,
provided this notice is included.
Contact Bill Muench concerning commercial use.
>You beg to differ with the eForth documentation? YYRRW.
I wrote that comment about the version with the 30 coded words,
for me, it is too slow for production work.
BUT, that is not the case if the model is coded for speed, one
of which is also included at the website:
http://www.baymoon.com/~bimu/forth/
It is true that my working versions are:
(different|complete|faster|smaller|(not free))
--
Bill Muench
Santa Cruz, California 95065
PS: I, myself, have never used the assembler version, I wrote it
with Dan Kelly. I have always ''meta-compiled'' for new
processors. Much easier and faster.
Ed Beroset
> Defensiveness seems to have gotten the better of you. (If there's a more
> fundamental reason for your behaving like a jerk, I'd like to know it.)
> If you can "configure/program/modify [your] products in the field with a
> PDA for example .. or a laptop", you can run a development system on the
> PDA or laptop. Clearly you know that, yet you pretend not to. Why?
Giving the OP the benefit of the doubt, it could be that when he read
"tethered system" he assumed that it meant something like an emulator or
the like -- i.e. "wires" and stuff. I don't know of a source for good
technical information on tethered Forth systems (or even a definition),
or I'd cite a URL. Have you got a source you could cite?
Ed
Elizabeth D Rather
> Hi Elizabeth,
>
> I see you still have not suitable advertising medium for your products
> ;-)
> .... maybe a new newsgroup called comp.lang.forth.free needs to be
> started ... an add-free zone ... my post was concerning "free" Forth's
> in C, not commercial ones.
I'm sorry you were offended. I don't believe you specified that you were
only interested in a free Forth in your original post.
> That aside, you seem to have missed the whole point of my post. In
> respect to "tethered" forth's for example. I don't want one. The
> reason is simple, I don't want to carry around the development system
> in the field. For example, I want to be able to
> configure/program/modify my products in the field with a PDA for
> example .. or a laptop .. or the kitchen sink, anything with a serial
> port.
As I pointed out, SwiftX offers an optional target-resident interpreter that
supports this.
> ...
> ... there are many
> succesful people out there using "Free" Forths in useful products ...
> commercial Forth's are "not" the only solution.
Yes, there are some pretty good free Forths out there. But the first effort
of someone who has never written one before is unlikely to be of the quality
of one written by someone who's done it before or has spent many years
polishing and tuning it. It is not difficult to get a Forth up and running.
It is far from trivial to make a really good one.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Jerry Avins
Sorry, no.
Elizabeth D Rather
news:Kvn8d.3834$gs1...@newsread2.news.atl.earthlink.net...
My definition would be one in which a host computer provides the principle
development support for a target connected by some means (serial, parallel,
etc.) and hosts an interactive connection with it for testing purposes.
Details vary depending upon the implementor (e.g. some may provide a more
transparent interactive interface than others).
Some information on ours is here:
http://www.forth.com/embedded/embedded-development.html. The optional
target-resident interpreter I mentioned is here:
http://www.forth.com/embedded/interpreters-emulators.html.
Guy Macon
Ed Beroset <ber...@mindspring.com> says...
>
>Jerry Avins wrote:
>
>> Defensiveness seems to have gotten the better of you. (If there's a more
>> fundamental reason for your behaving like a jerk, I'd like to know it.)
>> If you can "configure/program/modify [your] products in the field with a
>> PDA for example .. or a laptop", you can run a development system on the
>> PDA or laptop. Clearly you know that, yet you pretend not to. Why?
>
>Giving the OP the benefit of the doubt, it could be that when he read
>"tethered system" he assumed that it meant something like an emulator or
>the like -- i.e. "wires" and stuff.
I would like to see him try to develop code on one of these...
http://www.geocities.com/divastarzworld/newdivas.html
...without an external development system.
(The input portion of the I/O consists of Y/N buttons on
the shoes and resistor sensing to tell which clothing item
has been put on...)
Anton Ertl
>"Ed Beroset" <ber...@mindspring.com> wrote in message
>> "tethered system" he assumed that it meant something like an emulator or
>> the like -- i.e. "wires" and stuff. I don't know of a source for good
>> technical information on tethered Forth systems (or even a definition),
>> or I'd cite a URL. Have you got a source you could cite?
>
>My definition would be one in which a host computer provides the principle
>development support for a target connected by some means (serial, parallel,
>etc.) and hosts an interactive connection with it for testing purposes.
>Details vary depending upon the implementor (e.g. some may provide a more
>transparent interactive interface than others).
I have now added a section to the General/Misc FAQ:
5.11. What is a tethered/umbilical Forth system?
A tethered Forth system is a cross-development environment where the
host and the target are connected at run-time (during development),
allowing full interactive use of the target system without requiring
all the space that a full-blown Forth system would require on the
target. E.g., the headers can be kept completely in the host.
Tethered systems may also provide the compilation speed and some of
the conveniences of a full-blown Forth system on the host.
Tethered systems are also called umbilical systems.
Any comments?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
EuroForth 2004: http://www.complang.tuwien.ac.at/anton/euroforth2004/
Deadline (refereed): August 28, 2004; Conference: November 19-21, 2004
Guy Macon
>
>I have now added a section to the General/Misc FAQ:
>
> 5.11. What is a tethered/umbilical Forth system?
>
> A tethered Forth system is a cross-development environment where the
> host and the target are connected at run-time (during development),
> allowing full interactive use of the target system without requiring
> all the space that a full-blown Forth system would require on the
> target. E.g., the headers can be kept completely in the host.
> Tethered systems may also provide the compilation speed and some of
> the conveniences of a full-blown Forth system on the host.
>
> Tethered systems are also called umbilical systems.
>
>Any comments?
Should you mention the fact that sometimes you use a tether/umbilical
because the target lacks I/O? Maybe it has lots of space but no
keyboard or display.
andr...@littlepinkcloud.invalid
>> On the whole, it sounds like a fun project, but the result isn't really
>> appropriate for a serious project.
> It is this sort of snide patronizing comment that makes me want a want
> to push for a UseGroup that bans product Vendors.
human kind
Cannot bear very much reality.
Andrew.
[Eliot, 'Burnt Norton']
Anton Ertl
Serial I/O (or USB/Ethernet/whatever) would be good enough for a full
system. IIRC pbForth for Lego Mindstorms is a full system that works
through the infrared link.
Mass storage access (for the source code) from the target is a
potential problem but can also be done through the link to the host,
with a little bit of software on the host and the target; this is
already somewhat in the direction of a tethered system, but I would
not categorize it as such.
The other way lies the classical cross-compilation environment, where
you cross-compile on your host, burn the result into an EPROM (newer
technologies for that probably exist), put the EPROM into the target,
turn the target on, and see that it does not work (and maybe use an
in-circuit emulator (ICE), scope, or somesuch to see why).
Peter Lawrence
.
.
.
Of the Free Forth's eForth(or hForth) is
> the best assembly based solution *if* you have the commercial
> assembler for that micro .. and you have time for the port.
As I read it, eforth even lets you generate a Forth for a target system using
a different assembler, by only using its macros and ignoring its own code
generation functionality. The idea then is to have the 30-ish pieces of
machine code set up as bit patterns of data, with the rest of the high level
Forth still provided as data as before. Of course, the time problem goes up,
but it's a lot more practical than implementing a whole Forth for a virgin
machine with no tools for it. Traditionally, of course, you would go the
route of cross compiling from a different Forth platform. PML.
Ed Beroset
> Ed Beroset <ber...@mindspring.com> says...
>
>>Giving the OP the benefit of the doubt, it could be that when he read
>>"tethered system" he assumed that it meant something like an emulator or
>>the like -- i.e. "wires" and stuff.
>
> I would like to see him try to develop code on one of these...
>
> http://www.geocities.com/divastarzworld/newdivas.html
>
> ...without an external development system.
>
> (The input portion of the I/O consists of Y/N buttons on
> the shoes
Well, you could manually tap out I2C on her shoes...
and resistor sensing to tell which clothing item
> has been put on...)
Does it have speech synthesis? That could provide the feedback that a
monitor would ordinarily provide.
"That code, it's like, totally gross!"
Ed
Guy Macon
>>
>> http://www.geocities.com/divastarzworld/newdivas.html
>>
>> ...without an external development system.
>
>monitor would ordinarily provide.
>
>"That code, it's like, totally gross!"
That's *exactly* how she talks!
The speech is all in masked ROM.
Jerry Avins
> Ed Beroset <ber...@mindspring.com> says...
>
>>Jerry Avins wrote:
>>
>>
>>>Defensiveness seems to have gotten the better of you. (If there's a more
>>>fundamental reason for your behaving like a jerk, I'd like to know it.)
>>>If you can "configure/program/modify [your] products in the field with a
>>>PDA for example .. or a laptop", you can run a development system on the
>>>PDA or laptop. Clearly you know that, yet you pretend not to. Why?
>>
>>Giving the OP the benefit of the doubt, it could be that when he read
>>"tethered system" he assumed that it meant something like an emulator or
>>the like -- i.e. "wires" and stuff.
>
>
> I would like to see him try to develop code on one of these...
Which him, Mentink, or me?
Michael L Gassanenko
> [...] I would normally have to port an assembly version or put up with
> a large Forth written in C. So in the true nature of a Forth
> programmer, I have written my own "portable" Forth.
>
> My goals for this forth are:
>
> 1. Small, kernel < 25Kb for a 32 bit machine. ( ~ 220 words in kernel)
> (including headers)
> 2. Fast, not to be 'too much' slower than eForth.
> 3. Portable .. all that should be changed is the memory map, KEY/EMIT
> functions and specify the ENDIAN'ness
> 4. Full Interpreter on Target. (i.e NOT umbilical) I want to talk
> to/download to my target from anything that supports a serial port.
>
Personally I would like to see a Forth optimized for easiness of understanding.
Existing Forths writen in C are big and complex.
Maybe, some 10-20 primitives in C and the rest written in pseudo-Forth
(some syntax for threaded code that does not need Forth for parsing).
How would you link the dictionary? You cannot do it statically.
Unless you have one big array of bytes and use relative links....
Peter Lawrence
We've had discussions about morse code around here before. Clearly that's all
a real programmer needs :) PML.
rickman
I don't think that would require a "tethered" system, just a terminal.
Anton's definition indicates that the host is much more than just a
terminal, it is a significant part of the Forth system that is not
included in the target due to various constraints other than the lack of
a keyboard or display.
--
Rick "rickman" Collins
rick.c...@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
ebike
has ended up being 22k is size under Linux (x86) and performs 3x
faster than pForth and slightly slower than gForth on the same
platform running a sample of benchmarks.
I am currently testing on an embedded target. (Philips LPC21xx ARM7
based chip)
All that said, and due to all the negative feedback I have had in this
thread, I am very reluctant to release the code. If anyone *IS* very
interested then please make it known in this thread ... otherwise I
will just use it in my own products.
Have a nice day.
ebike
> of someone who has never written one before is unlikely to be of the quality
> of one written by someone who's done it before or has spent many years
> polishing and tuning it. It is not difficult to get a Forth up and running.
> It is far from trivial to make a really good one.
>
> Cheers,
> Elizabeth
And by what information do you have that this is my 1st Forth, and
what makes you assume that I cannot produce a good Forth? You are
wrong on both counts, but this is proberly because you "assume" I have
had very little programming experience, where in fact I have had > 30
yrs .... so Elizabeth please do not generalize, FREE forths are not
just written by the in-experienced. Some of us old-dogs like to
contribute back to society ... for nix, though if it's not wanted or
encouraged ... it makes the effort difficult.
Gary Chanson
"Peter Lawrence" <pet...@netlink.com.au> wrote in message
news:41641A...@netlink.com.au...
> Guy Macon wrote:
> >
> > Ed Beroset <ber...@mindspring.com> says...
> > >
> > >Guy Macon wrote:
> > >
> > >> I would like to see him try to develop code on one of these...
> > >>
> > >> http://www.geocities.com/divastarzworld/newdivas.html
> > >>
> > >> ...without an external development system.
> > >
> > >Does it have speech synthesis? That could provide the feedback that a
> > >monitor would ordinarily provide.
> > >
> > >"That code, it's like, totally gross!"
> >
> > That's *exactly* how she talks!
> >
> > The speech is all in masked ROM.
>
> We've had discussions about morse code around here before. Clearly that's
all
> a real programmer needs :) PML.
All they really need is a row of toggle switches. ];-)
--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
- http://www.mvps.org/ArcaneIncantations/consulting.htm
-gcha...@mvps.org
ebike
> Existing Forths writen in C are big and complex.
>
> Maybe, some 10-20 primitives in C and the rest written in pseudo-Forth
> (some syntax for threaded code that does not need Forth for parsing).
>
> How would you link the dictionary? You cannot do it statically.
> Unless you have one big array of bytes and use relative links....
Hi There,
Yes, graspForth is very easy to understand, is very small, has 70 very
small C primitives, the rest is in pseudo-Forth, as you say. I do have
a static array of heads .. and it is absolute .. manually linked ;)
Works very well. I have just finished it. It is 22k under linux and is
3x faster than pForth even though it is ITC.
Hans Bezemer
> In my opinion, you are shooting for the wrong target. There are
> other Forths that have kernels that are one half to one third of
> your 25KB, and they are mature, blazingly fast, and well-debugged.
> Your is a "me too" effort.
Well, many Forths are me-too efforts. They feature the same basic
engine, the same ANS-Forth vocabulary and they are used in the same
way. There are a few that are different:
OpenBios - doing Fcode
FICL - the way it interfaces with C
RetroForth - very minimal, very versatile, very portable
4tH - conventional compiler instead of Forth engine
ForthCMP - makes tiny, very speedy standalone executables
Except for RetroForth and ForthCMP, these are all C-based Forths. I
have seen a C-based Forth in 1K C-code (First??) some time ago in a
dutch Forth magazine. So, that has been done too.
> What I would like to see is a Forth that is optimized for absolute
> minimum not-written-in forth content, with *no* consideration given
> to speed issues. Barbie dolls don't need a fast Forth. Simple
> programs that run on multi-GHz machines don't need a fast Forth.
> Get your Kernel <4KB and it will fit in the L1 cache of just about
> every cached processor out there. Comment that <4K really well
> and it will be really easy to rewrite it for another processor.
> Do the rest of the system right and the kernel and some I/O code
> written in Forth are all you need to change to port to another
> system.
Forthers are still obsessed by either speed or size. True, speed is
not an issue anymore. When I started my compiler, it did a benchmark
in about 3 minutes. Now it does the same job in less than a second. A
speedier forth does it in less than a second too (although 10 times as
fast). That's why all this scripting stuff is getting more popular
than conventional compilers.
What I'm getting at is that instead of making clones of the same
concept over and over again one should better make a forth that does
something different or has a quality that others don't have. Think
about specifications before you hack together something that has been
done a million times before..! There is still room for diversity and
experimentation!
Hans Bezemer
Guy Macon
ebike <eb...@paradise.net.nz> says...
>All that said, and due to all the negative feedback I have had
>in this thread,
In my opinion, you came here with a combination of being very,
very sensistive to any comment even hinting that your design or
your code is less than perfect, combined with an extreme willingness
to criticize others and to make all sorts of personal comments.
>I am very reluctant to release the code. If anyone *IS* very
>interested then please make it known in this thread ... otherwise I
>will just use it in my own products.
I *was* quite interested, but then I realized that I won't be able
to make any comment about your program without you taking offense.
Where is the fun in trying out a new Forth if you can't discuss it?
Jay Hammond
on Linux in a spare moment.
I think graspforth might become stronger, more widespread & stabler if
lots of the lurkers on this newsgroup took it up. But if ebike hides his
graspforth it won't get noticed or improved. Of course if it's already
perfect, it should be released as a freebie so it can take over the
world. Or commercialised for a few tera$.
Ebike's code, ebike's choice.
best wishes, a lurker
Jeff Fox
> Forthers are still obsessed by either speed or size.
Better to say that Forth programmers pay attention to
what is important and often optimize in several dimensions
including speed and size of programs. In many embedded
applications getting the minimal cost means optimizing
for size and/or speed. In this realm this is the first
target for optimization. But of course there are other
dimensions for optimzation such as the portability and
ease of maintenance that Forth provides when done properly.
> True, speed is not an issue anymore.
For desktop computer users doing trivial things that is
probably true. For the majority of computers, embedded
computers, it is not true. If a cheaper computer when tuned
for speed can do what a more expensive embedded computer
can do then squeezing the required speed out of a cheaper
and slower and lower power chip may be the name of the
game.
I only have a 3G P4 and so speed is most definately an issue.
I crunched some numbers yesterday, the computation ran for 20
hours. I would have prefered it to take a half a microsecond
rather than 20 hours but speed is always an issue for any
non-trivial problem.
I tend to recoil whenever I hear people declare that
speed is not important anymore, that efficiency is not
important anymore, or that clear logical intelligent
thinking is not important anymore. But we do hear it
more and more frequently.
> What I'm getting at is that instead of making clones of the same
> concept over and over again one should better make a forth that does
> something different or has a quality that others don't have. Think
> about specifications before you hack together something that has been
> done a million times before..! There is still room for diversity and
> experimentation!
I will agree with you about that.
Best Wishes
Michael L Gassanenko
> Well I've finshed graspForth.
>
> thread, I am very reluctant to release the code. If anyone *IS* very
> interested then please make it known in this thread ... otherwise I
> will just use it in my own products.
May I have access to the code please?
I remember once or twice I needed something like what you describe.
Anyway, I myself would like to have a look at the thing.
BTW, IMO there *is* a need in minimalistic Forth written in C.
Michael L Gassanenko
> concept over and over again one should better make a forth that does
> something different or has a quality that others don't have. Think
> about specifications before you hack together something that has been
> done a million times before..! There is still room for diversity and
> experimentation!
What I expect is a Forth optimised for easiness of understanding/reuse.
No "navorots" (unnecessary complications).
GForth has a lot of navorots (e.g. superinstructions and OO wordlists),
PFE is a bit simpler but not as simple as possible.
So: "optimised for reuse cost". This will do as "a quality that
others don't have".
BTW, the use of ITC contributes to the low reuse cost because
ITC is one of good old approaches, it was intended to be
supported by the standard and by many code writers.
don groves
ebike at eb...@paradise.net.nz poured forth...
It looks like you're now getting as much positive feedback as
negative. Please do continue to keep us informed and release the
code for others.
Standards certainly have a place and are useful, but if we allow
them to stifle innovation, we are using them unwisely. The Forth
community has always been at the forefront of experimentation,
the language itself is ideal for it, long may it continue.
--
dg (domain=ccwebster)
Brad Eckert
Critical, yes.
Negative, no.
You are not threatening anyone's turf. Not the commercial users, not
the free forthers. We're all just trying to be helpful. You are free
to repeat our mistakes, though.
There are other Forths in C. How is yours better?
> Have a nice day.
Okay
--Brad
Metastabl
> thread, I am very reluctant to release the code. If anyone *IS* very
> interested then please make it known in this thread ... otherwise I
> will just use it in my own products.
>
> Have a nice day.
I would be interested and promise no negative feedback.
-Keith
Hans Bezemer
> han...@bigfoot.com (Hans Bezemer) wrote in message news:<eaef3280.04100...@posting.google.com>...
> > Forthers are still obsessed by either speed or size.
> applications getting the minimal cost means optimizing
> for size and/or speed.
the speed I experience when making specialized conversion programs for
PC's I don't agree. Scripting Forth saves me a lot of time there and
makes me a guru in my company. Not withstanding the fact that
'unreadable' forth gives me a kind of job security ;-)
> For desktop computer users doing trivial things that is
> probably true.
Most things in my professional life may seem trivial to you in that
respect, because they are jobs that are done in less than a second.
Like generating a PHP page from a SQL query in .1 seconds flat. Before
that, it could take 10 minutes and/or require a specialist. Now
everybody can do it and the effect on the availability of information
is immense.
> I only have a 3G P4 and so speed is most definately an issue.
> I crunched some numbers yesterday, the computation ran for 20
> hours. I would have prefered it to take a half a microsecond
> rather than 20 hours but speed is always an issue for any
> non-trivial problem.
Maybe we have a different view on what is trivial. Calculation of the
zillionth decimal of PI is trivial to me, no matter how many hours it
takes. A small, but powerful program that frees people from dull work
or the use of a specialist is non-trivial to me by any standard.
Hans Bezemer
Stephen Pelc
>Well I've finshed graspForth. It's currently is in Beta testing. It
>has ended up being 22k is size under Linux (x86) and performs 3x
>faster than pForth and slightly slower than gForth on the same
>platform running a sample of benchmarks.
>
>I am currently testing on an embedded target. (Philips LPC21xx ARM7
>based chip)
See:
www.mpeltd.demon.co.uk/usbstamp.htm
www.mpeltd.demon.co.uk/tiniarm.htm
and look at the Dev Kit Plus options. You once said
that you were building a racing bike. The VFX code
generator produces a racing Forth.
Unless you are committed to open source principles,
you'll find that the tools you need already exist at
very reasonable cost. How much have you spent so far
on mechanical parts and tools, and how much on software
tools?
Stephen
--
Stephen Pelc, steph...@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Jeff Fox
No. That's why I mentioned both embedded applications and
demanding desktop applications.
> Considering
> the speed I experience when making specialized conversion programs for
> PC's I don't agree. Scripting Forth saves me a lot of time there and
> makes me a guru in my company. Not withstanding the fact that
> 'unreadable' forth gives me a kind of job security ;-)
I did not say that scripting was not useful for quickly describing
applications as subsets of the features built into some application.
I was merely addressing your assertion that today speed is no
longer an issue. That overgeneralization implies that there is
nothing today but scripting and that's not true.
> > For desktop computer users doing trivial things that is
> > probably true.
> Most things in my professional life may seem trivial to you in that
> respect, because they are jobs that are done in less than a second.
Most things we do are trivial, and we don't even think about them
when we do them, they are completely automatic. Most human activity
does not require much thought, just reflex. And time is not always
a measure of complexity. Some programs may do a lot of computation
in a fraction of a second that would take a very long to do with
a pencil and paper, and sometimes a program that does almost
nothing, something you can do with a pencil and paper in less than
a second, and may take a very very long time to do it.
It is similar to measuring complexity by the raw size of a program.
People really need to get past the raw complexity that is visible
on the surface, size, time of execution, and recognize the
effective complexity of what a program is really doing.
> Like generating a PHP page from a SQL query in .1 seconds flat. Before
> that, it could take 10 minutes and/or require a specialist. Now
> everybody can do it and the effect on the availability of information
> is immense.
Layers of abstraction help raise productivity in many cases. Being
able to select data using SQL allows one to follow a standard when
the system is designed to support SQL. And one should be able to
pull records from a reasonably small database quickly. If it is
small enough speed with not be much of an issue.
> > I only have a 3G P4 and so speed is most definately an issue.
> > I crunched some numbers yesterday, the computation ran for 20
> > hours. I would have prefered it to take a half a microsecond
> > rather than 20 hours but speed is always an issue for any
> > non-trivial problem.
> Maybe we have a different view on what is trivial. Calculation of the
> zillionth decimal of PI is trivial to me, no matter how many hours it
> takes.
Yes but you know perfectly well that I was not talking about anything
like that. Calculating digits of pi for the zillionth time is a
relatively simple yet time consuming exercise and I agree that it
is a relatively trivial application as it does not demand a lot
of complex code or lots of memory. So we seem to agree to that
trivial is trival, but you seem to have ignored my example.
> A small, but powerful program that frees people from dull work
> or the use of a specialist is non-trivial to me by any standard.
By that definition all software is non-trivial. That's a semantic
dodge or you have very very low standards.
2 2 +
Now that's a non-trivial application isn't it? It frees the user
from the dull work of having to add two to two.
> Hans Bezemer
ur2c
> interested then please make it known in this thread
I am. Please let me try GraspForth.
Pesently I am a satisfied user of MinForth
http://home.arcor.de/a.s.kochenburger/minforth.html
ur2c
Stephen Pelc
wrote:
>Forthers are still obsessed by either speed or size. True, speed is
>not an issue anymore. When I started my compiler, it did a benchmark
>in about 3 minutes. Now it does the same job in less than a second. A
>speedier forth does it in less than a second too (although 10 times as
>fast). That's why all this scripting stuff is getting more popular
>than conventional compilers.
In terms of user interface design, anything that takes less
than 0.1 seconds can be regarded as instantaneous. So it's
a sort of boundary condition.
Not long ago the chief salesman of a client took me into
his office and performed the same project update on the
same application under ProForth for Windows and VFX Forth
for Windows on the same PC. The VFX version was more than
ten times as fast. He thought that was wonderful.
Speed matters.
Jeff Fox
No. That's why I mentioned both embedded computing and
demanding desktop applications as environments where speed
definately matters. I realize that speed is not particularly
important to a class of scripting applications, but I did
not suggest that embedded computing and demanding desktop
applications should be the only place where Forth can be used.
I did not suggest that Forth cannot be used for scripting.
I did not agree with your implication that we should limit
Forth to a certain class of scripting where speed was not
important. Your statement was a blanket, speed is not
important anymore. That's why I mentioned that it was
not true for many embedded apps and demanding desktop
applications.
> Not withstanding the fact that
> 'unreadable' forth gives me a kind of job security ;-)
IMHO that is the most serious and damaging form of Forth
abuse, writing intentionally unreadable code! Shame.
It is also software abuse regardless of the language involved.
You should know that promoting Forth as unreadable is a very
bad thing even if you get paid to do it. Taking money for
promoting negative sterotypes doesn't make it right.
> > For desktop computer users doing trivial things that is
> > probably true.
> Most things in my professional life may seem trivial to you in that
> respect, because they are jobs that are done in less than a second.
Most things people get paid to do are booring, and trivial. Most
things people do are things that they do by reflex. They tend not
to be aware of how fantastically complicated many things they do
by reflex really are or how incredibly trivial the thinking that
they do that goes along with those actions is.
But the time a program runs, or its size are not good measures of
effective complexity, and are only indicators of raw complexity.
A trivial program may be very large and very slow, or a non-trivial
program may be small and fast.
> Like generating a PHP page from a SQL query in .1 seconds flat. Before
> that, it could take 10 minutes and/or require a specialist. Now
> everybody can do it and the effect on the availability of information
> is immense.
Yes, and using the computer is no doubt much faster than selecting
records by hand from a large paper database. Generating a report
from a database is the sort of thing some of the earliest Forth
applications did. They were used in a similar scripting manner
to increase the productivity of the database users.
> > I only have a 3G P4 and so speed is most definately an issue.
> > I crunched some numbers yesterday, the computation ran for 20
> > hours. I would have prefered it to take a half a microsecond
> > rather than 20 hours but speed is always an issue for any
> > non-trivial problem.
> Maybe we have a different view on what is trivial.
Probably so.
> Calculation of the
> zillionth decimal of PI is trivial to me,
Yes, I agree. It isn't very complicated, doesn't need much code
or much memory space until you need to store a zillion digits
somewhere. I am not sure how many digits a zillion is but it
would become a non-trivial problem if it dwarfs the entire
memory of a PC. Just like calculating and counting primes is
a trivial problem until you start talking about zillions of
digits. As long a a computer can represent a zillion in a
reasonably efficient way calcuating the zillionth digit of
PI is relatively trivial (once you find the non-trivial
algorithm. If you had to work it out yourself from scratch
it would be a bigger problem.)
> no matter how many hours it takes.
Time is no measure of complexity. A program that takes an hour
to print 'Hello World' may just have a delay loop or be blocked
by some other task until it gets it chance to run.
> A small, but powerful program that frees people from dull work
> or the use of a specialist is non-trivial to me by any standard.
1 1 +
I have just written a non-trivial program because it frees people
from the dull work of having to add one to one. I does not require
a person trained in mathematics. It did require a programming
specialist like myself to write such a non-trivial application.
Why it takes humans years to learn to add one to one. It requires
a powerful program to compete with something that it takes most
humans years to learn. I think your definition of non-trivial
is too trivial. It looks like you are just shifting to your
own definition of 'powerful' to define your own definition of
trivial.
It will always be a value judgement. What is considered a
trivial problem to one person is considered a non-trivial
problem to anther. This how we tend to measure intelligence.
It is a relative thing. What is easy to some is hard to
to others, what is hard to some is impossible to others.
Problems that are average to the average person will be
hard to those with below average intelligence and be easy
for those with above average intelligence. The line between
hard and easy will be just like the line between trivial and
non-trivial. Where it goes will depend on whom you ask.
Best Wishes
ebike
I'm commited to open-source principles...
ebike
on a number of embedded targets.
Can anyone point me to a location to upload to that everyone can get
at?
Thanks.
Stefan Schmiedl
Jeff Fox <f...@ultratechnology.com> wrote:
> han...@bigfoot.com (Hans Bezemer) wrote in message news:<eaef3280.04100...@posting.google.com>...
>
>> 'unreadable' forth gives me a kind of job security ;-)
>
> IMHO that is the most serious and damaging form of Forth
> abuse, writing intentionally unreadable code! Shame.
Even the best Forth code will be "unreadable" to people
not knowing Forth. I think that was what Hans refered to.
>
> It will always be a value judgement. What is considered a
> trivial problem to one person is considered a non-trivial
> problem to anther. This how we tend to measure intelligence.
> It is a relative thing. What is easy to some is hard to
> to others, what is hard to some is impossible to others.
I have fond memories of a former Math prof of mine, who said
"Well, the proof is trivial." and wondered why we did not
agree with him, after using three large blackboards to put
it down.
s.
Jerry Avins
Probably anything with a URL.
Jerry
--
When a discovery is new, people say, "It isn't true."
When it becomes demonstrably true, they say, "It isn't useful."
Later, when its utility is evident, they say, "So what? It's old."
a paraphrase of William James
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Jeff Fox
> Speed matters.
You will get a lot of sour grapes reactions today. Speed is
probably not important to anyone who can't get it. So many
people who are locked out will declare that speed doesn't
matter anymore. To them it doesn't, it can't.
Best Wishes
rickman
I can provide web space. I have several URLs including www.armforth.com
which you can use. Can you put together a page, or would you like me
to?
John A. Peters
Sign up for, and open a chat group at
http://groups.yahoo.com/
See the center of the page where it says
STAR A NEW GROUP!
It is easy and there is space to upload file.
Then tell us pabout it here.
John A. Peters
Hans Bezemer
> Even the best Forth code will be "unreadable" to people
> not knowing Forth. I think that was what Hans refered to.
because I have to maintain it myself. On the contrary, I try to write
code as clear as I can (which is not always easy when you have to do
some stack acrobatics). Forth knowledge is rare these days, whether we
like it or not. To put Jeffs mind to ease, a few snippits:
\ Copyright 2001,4 Fortis Bank
\ Written by Hans Bezemer
\ 010314 = V1.0 Initial version
\ 010327 = V1.1 Full pathnames added
\ 020220 = V1.2 Implemented new keywords
\ 020301 = V1.3 Updated for V3.3d RC1
\ 020730 = V2.0 Rewrite for Tivoli V4
\ 020806 = V2.1 Added ProcessField
\ 020916 = V2.2 Updated for V3.3d RC2
\ 020918 = V2.3 Updated for V3.3d RC3
\ 030409 = V2.4 Updated for V3.3d2
\ 030506 = V2.5 Updated for new Tivoli
\ 031009 = V2.6 Updated for V3.4a RC1
\ 040316 = V2.7 Updated for V3.4e
\ 041004 = V2.8 Optimized version
\ 041005 = V2.9 Commandline arguments
char ; constant ";"
: Field> ";" parse ; ( -- a n)
: .Field ";" dup parse type emit ; ( --)
: MergeFiles ( h -- h)
begin \ Merge AllSys en Procs file
dup use refill \ use AllSys file for input
while
";" dup dup emit \ emit a semi-colon
parse 2dup type pad place emit \ get altname
.Field .Field Field> type [char] .
emit .Field .Field .Field .CPU \ get processor info
repeat
;
IMHO I've seen worse.. ;-) This baby merges two dumped mail messages
containing lists into one .CSV file, picking up an identifier in one
file and looking it up in another file, returing the number of CPU's
and their speed.
Hans Bezemer
Hans Bezemer
much code
or much memory space (..)
But the time a program runs, or its size are not good measures of
effective complexity, and are only indicators of raw complexity.
A trivial program may be very large and very slow, or a non-trivial
program may be small and fast.
I did not suggest that Forth cannot be used for scripting.
I did not agree with your implication that we should limit
Forth to a certain class of scripting where speed was not
important. Your statement was a blanket, speed is not
important anymore. That's why I mentioned that it was
not true for many embedded apps and demanding desktop
applications."
I've taken just a few snippits from your response to show that was
exactly what I'm pointing at:
1) Like you say, 'trivial' has nothing to do with speed. Non-trivial
programs may be done using a slow scripting Forth, trivial programs
may require a blindly fast forth. So let's get rid of the 'trivial'
word (FORGET trivial).
2) I like (and we've already agreed on that) very different Forths.
Some may be avant garde, some quite classic, some may be leaning to
ANS, others may be full ANS, some may be very different (like 4IM or
ColorForth), some big, some compact, some fast, some slower. There is
a niche ( and will continue to be a niche) for them all. What we don't
like is "me-too" compilers that have been done a zillion times before
and add nothing to the Forth universe.
3) I tend to think that we agree that the world has changed since 1983
when I first loaded my Z80 assembler based Artic Forth. My C-based
Forth does a benchmark in 0 flat while my assembler based forth (in
1983) did it in slightly less than an hour. THAT MEANS THAT A LOT OF
TASKS CAN NOW BE DONE BY COMPARETIVELY SLOW FORTHS. That also means
that we have a shift.. Fast forths and compilers are moving to the
high end (which was the realm of 'impossible' in the early days). I
tell you: if Moores law continues to be true, we'll see complete
desktop environments (including mail clients, wordprocessors, etc.)
being written in Perl, Python, Tcl/Tk etc. And nobody will ever look
back..
If you think I've taken these quotes from their context, I'm very
sorry because that was not my intention. I just wanted to show that
we're quite close what Forth is concerned. My conclusion is, that
there is still room for fast Forths, but their field of application
has shifted upwards (where compactness and speed matters).
Applications that used to require a fast Forth are taken by Forths
(and other scripting languages) with different qualities, simply
because they have added value in some field or another.
Denying that there is no room left for fast, compact Forths is denying
that there are no challenges left. That was not the message I
intended. But denying there is no room for slower scripting languages
(except for the trivial crumbs that fast compilers leave) is denying
that 20 years have gone by. I don't think that is the message you
intended.
Hans Bezemer
Jeff Fox
> exactly what I'm pointing at:
You might have left a greater than symbol in the left column so
that people could distinguish what I wrote previously from what
you added in you last reponse. It will confuse people without
any indiciation of who wrote what. But let's hope that it doesn't
cause too much confusion or derail the thread.
> 1) Like you say, 'trivial' has nothing to do with speed. Non-trivial
> programs may be done using a slow scripting Forth, trivial programs
> may require a blindly fast forth. So let's get rid of the 'trivial'
> word (FORGET trivial).
Perhaps we need to distinguish between trivial problem and trivial
program. If a problem requires an interupt response in less than
100ns the program that does it may be trivial, but the problem that
it solves is not trivial. Most hardware and software simply can't
do it.
And some trivial problem can be solved by a non-trivial program.
I mean you can print 'Hello World' with a 100MB non-trivial
program. But the problem that it solves really is trivial and
all the complexity added to the program really is added on.
One may argue that no one can call the 100MB program trivial,
but if it solves a trivial problem I will say that it is trivial
no matter how large or slow it is.
People seem to confuse bloated inefficient software for software
doing non-trivial things. Just because it is big and slow doesn't
make it non-trivial. Just because something is small and fast
doesn't make it trivial. I tend to make the classification based
on the nature of the problem being solved. Solving non-trivial
problems is the basis of non-trivial programs the way I see it.
> 2) I like (and we've already agreed on that) very different Forths.
> Some may be avant garde, some quite classic, some may be leaning to
> ANS, others may be full ANS, some may be very different (like 4IM or
> ColorForth), some big, some compact, some fast, some slower.
OK.
> There is
> a niche ( and will continue to be a niche) for them all. What we don't
> like is "me-too" compilers that have been done a zillion times before
> and add nothing to the Forth universe.
Sure but if you realize that there are so many different types of
Forth I would think you would realize that there is more out there
than just scripting Forths and not declare that 'speed is not important.'
That was the statement that discounted all the Forths where speed is
most definately important.
Now if you want to say that 'Speed is not important to me.' I would
not have said anything. I simply pointed out that there are also
Forths where speed is important.
Now you seem to acknowledge that there are many kinds of Forth and
that speed is important to some. That's all I was getting at.
You have refuted your own comment that speed is not important even
if you haven't retracted it.
> 3) I tend to think that we agree that the world has changed since 1983
Duh? Why wouldn't you agree? Been in a coma or something? Who would
not agree that the world (or the world of personal computing) has
changed since 1983.
> when I first loaded my Z80 assembler based Artic Forth. My C-based
> Forth does a benchmark in 0 flat while my assembler based forth (in
> 1983) did it in slightly less than an hour. THAT MEANS THAT A LOT OF
> TASKS CAN NOW BE DONE BY COMPARETIVELY SLOW FORTHS. That also means
> that we have a shift.. Fast forths and compilers are moving to the
> high end (which was the realm of 'impossible' in the early days). I
> tell you: if Moores law continues to be true, we'll see complete
> desktop environments (including mail clients, wordprocessors, etc.)
> being written in Perl, Python, Tcl/Tk etc. And nobody will ever look
> back..
Nobody? ;-) I think everyone would be facing backwards at that
point. Some will still be looking forward.
> If you think I've taken these quotes from their context, I'm very
> sorry because that was not my intention.
I don't think that has happened.
> I just wanted to show that
> we're quite close what Forth is concerned. My conclusion is, that
> there is still room for fast Forths, but their field of application
> has shifted upwards (where compactness and speed matters).
OK, that's all I was looking for. That statement contrasts your
earlier blanket statement that speed isn't important.
Of course I also think it has shifted downward into the embedded
arena. Many embedded apps are more demanding today and require
more speed than in the days when such apps were impractical.
> Applications that used to require a fast Forth are taken by Forths
> (and other scripting languages) with different qualities, simply
> because they have added value in some field or another.
That's the trend. The 'added value' is added value in some dimension
but also has added costs associated with it in other dimensions.
> Denying that there is no room left for fast, compact Forths is denying
> that there are no challenges left.
My original objection was only to your denying that there is room
for fast or compact Forths now that speed simply doesn't matter.
Now that you have been coaxed into reversing your position on
that I see no further reason to comment on your opinions.
> That was not the message I intended.
You should realize that your blanket statement that speed no
longer matters was going to convey a meaning that was perhaps
not the one that you intended. You essentially denied the
need for any high performance Forths.
Then when I said that there are ALSO Forths where speed IS
important you said that I claimed that there was no place for
scripting Forths! No I simply said that speed is still important
for non-scripting Forths.
> But denying there is no room for slower scripting languages
But no one ever said that. All that was said was that you were
wrong that speed is not important for anywone and that scripting
is the only thing that counts.
In pointing out that you were wrong about scripting being the
only thing and there no longer being any need for high performance
Forth you seem to have reacted by thinking that I said that
there was no place for scripting Forths. Sorry no one said that.
I did say that scripting is useful for quicly solving relatively
trivial problems. I guess that offended you personally.
> (except for the trivial crumbs that fast compilers leave) is denying
> that 20 years have gone by.
No not at all. I is just denying that trivial problems are more than
trivial problems. Sorry if you don't like that comment, nothing
personal, try not to take it personally.
Scripting languages essentially automate creating custom scripts
that leverage off the complex features of some underlying system.
The real complexity is in the underlying systems, the scripting
languages form a thin layer on top to help doing things that
the underlying system is really going to do, things that the
underlying system makes trivial. What scripting does is add
a trivial layer of control on top of perhaps non-trivial
systems. Scripting is handy for creating these relatively
trivial scripts.
Once an application or a system has been written that can do
lots of complex things it is fairly trivial to add a scripting
layer that simply selects those predefined non-trivial functions.
Scripting itself is inherently trivial.
Useful? Yes. Non-trivial? No. Popular? Yes. The only thing,
as in "speed isn't important anymore" ? No. That was my point.
You were wrong with the blanket statement that speed is not
important period.
> I don't think that is the message you intended.
The message that there have been no changes since 1983 was
definately not my message. I don't really think that you
could have possibly read that in my message either. ;-)
Best Wishes
Richard Owlett
I strongly advise one and all to read YAHOO's "privacy policy" [sic]
at http://privacy.yahoo.com/privacy/us/
Start careful reading at heading "Information Collection and Use"
My reading is that when using YAHOO, you have NO privacy.
Some time back it was suggested I participate in a YAHOO group. I became
concerned about some of the information requested to register. Neither
email NOR phone call to YAHOO got any response.
*YMMV* !!
In my VERY personal opinion, requesting anything other than name and a
valid email address supported by your ISP is going too far. That much is
required for policing possibly abusive posts. You should be allowed to
post to the group with an anomomus address to avoid spam from harvesters.
P.S. If anyone reading this has an in with YAHOO, please "rattle their
cage".
Richard Owlett<row...@atlascomm.net> is my real name and valid email
address. [ My ISP provides an excellent spam/virus filter as part of my
basic service ;]
ebike
Just to let you know my port of graspForth to the Philips LPC21xx ARM
chip
took literally all of 5 mins, and ran out-of-the-box.
The code size was 16K.
I am now going to try on a mips platform and maybe a strongArm. Once
this is done and I have done further code tidy-up, I will Post my
efforts.
rickman
Nice. Too bad it is not targeted to small memory space processors
(umbilical). But keep up the good work. :)
rickman
pretty standard to me. When they list all that info that they "collect"
they are not saying that you *have* to provide it. I use Yahoo email
addresses all the time and I never give them anything but the minimum
info and I never give them honest info (fake name). In fact, I am
running two Yahoo groups (OKI-ARM-mcus and hForth). I don't think I
have given them any real info about me. Of course they can track my IP
address. That used to be no problem since a dial up IP changes every
time you dial. But now that I have cable modem, my IP doesn't change
even when I reboot the modem.
--
Ed
"Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
news:2004Oct...@mips.complang.tuwien.ac.at...
>
> [snip]
>
> I have now added a section to the General/Misc FAQ:
>
> 5.11. What is a tethered/umbilical Forth system?
>
> A tethered Forth system is a cross-development environment where the
> host and the target are connected at run-time (during development),
> allowing full interactive use of the target system without requiring
> all the space that a full-blown Forth system would require on the
> target. E.g., the headers can be kept completely in the host.
> Tethered systems may also provide the compilation speed and some of
> the conveniences of a full-blown Forth system on the host.
>
> Tethered systems are also called umbilical systems.
>
> Any comments?
Sounds good but is perhaps biased toward certain systems.
There's usually trade-offs between having the target 'dumb'
or 'smart'. On the latter - RSC-Forth, Inner Access Super-8
forth, Payne 8051, MaxForth (?) etc - the target was used to
do the development. Often the target board would have two
roms - a kernel rom and a separate (removable) development
rom.
Ed
Richard Owlett
The group I was thinking of joining had two levels of particiapation:
1. a mailing list with send and recieve priveedges
2. a file download area
To participate in the first, only a valid email address was required.
To participate in the second a rather detailed form was presented. Among
other items it requested physical address, age, gender, and income
level. I balked at that.
Wolf Wejgaard
You can have the full interactivity of a classical Forth system
also in a tethered arrangement. There are practically no
trade-offs if you do it the right way. The main benefit of
separating host and target is - for me - that the whole target
code is explicitly defined in your source text, thus you are in
control of every byte of the application. You can change
everything including the kernel words and the Forth machine, thus
create lean targets if needed. Yet you are still able to test
every word interactively and, in principle, to single step
through the whole application - both Forth and assembler code.
You could even change the code of every word in the loaded
program on-the-fly. And you don't have to stop the program for
the change, which is quite handy if your program is controlling a
large machine that can't simply be stopped and restarted. All
this using a tiny monitor in the target, which can be excluded
from the final code if you are hard pressed.
I have found Forth to be at its best in the umbilical situation.
It is a pity, IMO, that umbilical Forth development is generally
used 'down' to lean embedded targets. It is just as valuable for
applications running on the same OS as the host and even 'higher
up'. As an example: HolonForth is based on DOS and in its main
implementation creates separate DOS applications. There are now
Holon versions for the 68hc11 and other microsystems, but I have
also experimented with a DOS-to-Windows development system, and
have implemented a full DOS-to-Java version for umbilical Forth
program development on the JVM. The technique seems to be
universally applicable.
BTW: Who invented the umbilical development technique, does
anyone here know? I have seen it outside of Forth, e.g. it is
used in Motorola's PCBUG11 debugger.
Wolf Wejgaard
rickman
>
> The group I was thinking of joining had two levels of particiapation:
> 1. a mailing list with send and recieve priveedges
> 2. a file download area
>
> To participate in the first, only a valid email address was required.
>
> To participate in the second a rather detailed form was presented. Among
> other items it requested physical address, age, gender, and income
> level. I balked at that.
Yes, they may have spaces for all that on the form, but do they
*require* that you supply that info? To sign up for a lot of things on
Yahoo! they ask for a lot of info, but little of it is required, you can
just leave it blank. Was that the case here?
Hans Bezemer
> program. If a problem requires an interupt response in less than
> 100ns the program that does it may be trivial, but the problem that
> it solves is not trivial. Most hardware and software simply can't
> do it.
'trivial'. Shifting the discussion from 'trivial' programs to
'trivial' problems doesn't help much. If I can't put a figure on
something and nail it to the wall, it doesn't exist for me. That's why
my shredder has eaten many specifications that said 'user-friendly'
which is not quantitive too.
> Sure but if you realize that there are so many different types of
> Forth I would think you would realize that there is more out there
> than just scripting Forths and not declare that 'speed is not important.'
> That was the statement that discounted all the Forths where speed is
> most definately important.
>
> Now if you want to say that 'Speed is not important to me.' I would
> not have said anything. I simply pointed out that there are also
> Forths where speed is important.
>
> Now you seem to acknowledge that there are many kinds of Forth and
> that speed is important to some. That's all I was getting at.
> You have refuted your own comment that speed is not important even
> if you haven't retracted it.
doing PC's and Midrange machines all my life. It seems you've been
doing embedded applications. I see this development:
S = interpreted or semicompiled
C = midrange compilers (e.g. Turbo C, MS compilers, standard compilers
on Unix)
H = Assembler or high end compilers
1975 - 1985 Home computer era
==
S - Data entry
H - Batch programs (conversion, data manipulation)
H - General purpose applications (word processing, email, spreadsheet)
H - Games (apart from Startrek and moonlander ;-)
1985 - 1995 The PC era
==
S - Data entry
C - Batch programs
H>C - General purpose
H>C - Games
1995 - 2005 The revenge of the interpreters
==
S - Data entry
S - Batch programs
C>S - General purpose
C - Games
2005 - 2015 The future according to the Beez'
==
S - Data entry
S - Batch programs
S - General purpose
C>S - Games
Forth bloomed in the Home computer era. It was the only compiler that
allowed me to do real high-speed work on a Sinclair Spectrum without
resorting to Z80 assembler. It was used in Atari game modules. It
quickly lost significance due to the rise of Turbo Pascal in the PC
era (which was about 35K (bare compiler)).
However, Lotus 1-2-3 was still written in assembler. Nowadays we even
see the first IDEs, editors and even simple word processor written in
scripting languages (semi compiled, that is. PHP, Perl are all semi
compiled).
My first database application was written in ZX-Basic and took 10
hours to sort 650 entries. Z80 assembler did it in two minutes.
According to some calculations I made this weekend semi compiled 4tH
would do it in less than 10 seconds (conservative estimate on a 600
MHZ PIII).
The statement I wanted to make was there are more and more
applications coming in the range of semi-compiled scripting languages,
since less than a second performance remains less than a second
performance.
> > I just wanted to show that
> > we're quite close what Forth is concerned. My conclusion is, that
> > there is still room for fast Forths, but their field of application
> > has shifted upwards (where compactness and speed matters).
>
> OK, that's all I was looking for. That statement contrasts your
> earlier blanket statement that speed isn't important.
>
> Of course I also think it has shifted downward into the embedded
> arena. Many embedded apps are more demanding today and require
> more speed than in the days when such apps were impractical.
See above. I don't want to erradicate fast forths. Like I showed
above, their field of application has narrowed (or specialized if you
prefer).
> > Applications that used to require a fast Forth are taken by Forths
> > (and other scripting languages) with different qualities, simply
> > because they have added value in some field or another.
>
> That's the trend. The 'added value' is added value in some dimension
> but also has added costs associated with it in other dimensions.
Added costs can also be the maintenance costs. Assembler is harder to
maintain and there are less (and thus more expensive) programmers
available for the job. Maintenance is one of the most demanding
questions of our time. The market is changing rapidly, so are
applications. Reengineering unmaintainable code and rebuilding it is
extremely expensive (Bell labs => software decay). Writing unreadable
code (that you assumed I did) is shooting in your own leg. Code is
like a shark: it has to move or it dies.
> My original objection was only to your denying that there is room
> for fast or compact Forths now that speed simply doesn't matter.
> Now that you have been coaxed into reversing your position on
> that I see no further reason to comment on your opinions.
No, I haven't changed my opinion, see above. I just took the reverse
side of the overall opinion here that small and fast is the only way
to go and everything else is not worth mentioning. We see ourselves
still too much as the extreme elite of programmers (hey, who didn't
write his own pet Forth compiler over here? Try comp.lang.c for that
matter) and still wonder why Forth remains so obscure. "If your screen
goes black and your keyboard freezes, you made an error. So don't do
it".
> I did say that scripting is useful for quickly solving relatively
> trivial problems. I guess that offended you personally.
I see too often that we're like a bunch of custom powercar builders
over here, racing the circuit with low weight, massive V12 engine cars
and wonder why there are so few families using it to do shopping. Is
shopping trivial? May be, but it makes a hell of a lot more sense in
everyday life than making laps around the track.
I love this language. I want to see it used. People at work wonder why
I'm able to make these conversion programs so quickly and are even
more amazed when I show them I did it in a handful of lines where they
need pages of visual basic. For many, it is their first encounter with
forth..
I love this language. I don't want to see it die..
Hans
Jeff Fox
> I still tend to have problems with the non-quantitive nature of
> 'trivial'. Shifting the discussion from 'trivial' programs to
> 'trivial' problems doesn't help much. If I can't put a figure on
> something and nail it to the wall, it doesn't exist for me. That's why
> my shredder has eaten many specifications that said 'user-friendly'
> which is not quantitive too.
The nature of natural language is that definitions of words
involve other definitions and one can almost never put a figure
on something and nail it to the wall. No communication can take
place between people when one insists that all definitons be
giving in figures and nailed to a wall.
> > Now you seem to acknowledge that there are many kinds of Forth and
> > that speed is important to some.
I have acknowledge that from the start and have been trying to get
you to acknowledge it and realize that your blanket 'speed is not
important' statement was not an acknowledgement that there are
other kinds of Forth than the scripting that people do where
they consider speed to not be important. You seem to be trying
to reverse the situation to suggest that it was I who originally
stated that speed is the most important thing in all cases. No
I stated that there are embedded apps and demanding desktop apps
that are apparently outside of your limited world where you declare
that speed is simply not important.
Trying to reverse the situation, to make me out to be the who
started out making the untrue and narrow minded blanket
statements about speed simply not being important period. Anyone
who have been reading the thread can see that you are now in
full retreat and trying to cover your tracks by suggesting that
'Now' I 'seem to acknowledge' ... when if fact that was my
point from the begining, I was just trying to get you to
acknowledge that and retract your false blanket statement
that speed is simply not important period.
You haven't admitted to making the false statement, but now
that you have agreed to agree with me you want to say that now
I have agreed with you. Not exactly. You were wrong. You have
apparently gotton off the narrow minded position that speed is
simply not important and accepted that there are also many
other cases, other than yours, where speed is important.
I accepted from the start that speed was not important to some
people. You reject the concept that speed was important to
anyone by simply stating, speed is not important without
any qualification.
> > You have refuted your own comment that speed is not important even
> > if you haven't retracted it.
> Well, there seems to be an appreciation of our environments. I've been
> doing PC's and Midrange machines all my life. It seems you've been
> doing embedded applications. I see this development:
I have been doing microprocessors since they were invented, desktop
and embedded for thirty years. I have done mainframes and minis and
full custom specialized ECL and CMOS computers, and parallel computer
on various platforms. Most of the development tools and most of the
programs are PC based these day and are very demanding.
In both demanding, non-trivial, PC applications and great number
of embedded systems speed is important. Speed is important for
super computing and parallel computing. Why else would people
spend many millions on large parallel machines is not to do
non-trivial computation?
I have dealt with local networks, and systems that had 30
different networks with every kind of equipmeent imaginable
at places like Pac Bell and Bank of America. I have dealt
with data entry types, mainframe batch programmer types,
word processors, and lots of other people in the computer
industry who do such slow work that speed is not important
to them. To those who solve more complex problems and
have to deal with non-trivial problems and programs speed
is important.
I realize that most people are not programmers and simply use
whatever consumer software comes bundled on their computers.
Their modern computer seems fast enough for word processing and
doing email or browsing the web. The computers are more than
fast enough to keep up with their typing while they are doing
these things so they get the impression that speed is not an
issue in computing.
And there are people who write scripts of one form or another.
Often they don't care how fast they are. Sometimes they prefer
them to be slower rather than faster. This limits how much work
and how much thinking they have to do to get paid. The slower
their software the less mental work they have to do to keep up.
They sometimes get the impression that speed is not important
and that no one else does anything but slow scripting, but
they are wrong about that. That sometimes leads them to
make ridiculous statements such as 'speed is not important period.'
If I gave you a similar list of my experiences you would not
a lot of custom work, designed to squeeze the last bit of speed
out of demanding state of the art new hardware and software.
You will see that my experience is not limited to data entry,
batch processing, general purpose consumer programs and games.
I have not limited my experience to non-demanding computing
applications.
It is clear from your background that speed is not important to
you. For data entry and batch processing and word processing
it really doesn't matter. For your games you probably prefer
faster frame rates, more detail, more intelligent behavior
by agents, etc. Or then again you might be into adventure
games where you pick up the magic key under the magic mat
and put it in your ear to gain magical powers. For that type
of game speed is not going to be important, it will be a
lot like data entry. I am beginning to get an impression of
just how limited your experience has been.
> Forth bloomed in the Home computer era. It was the only compiler that
> allowed me to do real high-speed work on a Sinclair Spectrum without
> resorting to Z80 assembler. It was used in Atari game modules. It
> quickly lost significance due to the rise of Turbo Pascal in the PC
> era (which was about 35K (bare compiler)).
> However, Lotus 1-2-3 was still written in assembler. Nowadays we even
> see the first IDEs, editors and even simple word processor written in
> scripting languages (semi compiled, that is. PHP, Perl are all semi
> compiled).
Yes. NOWADAYS hardware is fast enough to do trivial things using
scripting languages. They help keep the runtime efficiency down
which helps sell hardware and software upgrades. The consumers
don't notice that they pay extra because of the governers built
into these systems.
Your account of history is accurate. But other than detailing
that speed was never important to data entry operators or
batch programmers and that there are a lot of these types
these days now including scripters to explain your limited
experiece I don't really see your point. I guess you are
just tying to explain why you have the mistaken impression
that speed is simply not important to you that it is simply
not important period. Not everyone working with computers is
mostly doing things like data entry.
> My first database application was written in ZX-Basic and took 10
> hours to sort 650 entries.
Couldn't a minimum wage worker without a computer do it much much
faster than that? 10 hours to sort 650 entries? You must be kidding.
I mean I know a 1Mhz 8080 is pretty slow, but that is ridiculous.
I guess there is no upper limit for how inefficient a program can be.
> Z80 assembler did it in two minutes.
2 minutes? Your kidding, and Z80 were much faster than 8080.
I guess by only working in assembler for the first couple of
years on the 8080 I got a feeling for how fast it could be.
I was dealing with A/D D/A 3D games, speech and image recognition,
and stuff like that on those old machines. Video compression, AI,
3D realtime multiplayer games, and similar applications simply
would be useless if they ran as slowly as a program that took
two minutes to sort 650 values.
> According to some calculations I made this weekend semi compiled 4tH
> would do it in less than 10 seconds (conservative estimate on a 600
> MHZ PIII).
The number that a minimum wage employee can sort per minute has
gone down too. So now a Pentium can actually sort faster than a
human, impressive.
> The statement I wanted to make was there are more and more
> applications coming in the range of semi-compiled scripting languages,
> since less than a second performance remains less than a second
> performance.
True. And there is nothing wrong with that other than the fact that
it gives some people the mistaken impression that it means that
speed is simply not important anymore.
> Added costs can also be the maintenance costs. Assembler is harder to
> maintain and there are less (and thus more expensive) programmers
> available for the job.
I think that there is a common misconception in the above statement
that exposes a false assumption. People often say what you said, but
it suggests that there is 'an assembler' that can be compared to
the ever popular higher level languages. But the fact is that there
is not an assembler. There are as many assemblers as there are
processor designs. (more if you count implementations rather than
CPU types.)
Sure Pentium assembler is a nightmare as is assembler for almost
any modern deeply pipelined or multi-cached chip designs. Sure
comparing dreadful Pentium assembler to virtually any high level
language will expose a big difference in maintenance. But Pentium
assembler is thankfully not the only assemler and not characteristic
of all assembly langague.
For instance, there are chips where the assembler is really a
form of Forth. Being a form of Forth this type of assembler
is close to a high level language than it is to something like
Pentium assembler. So statements about how programming in
assembler makes for maintenance problems is certainly true if
you talk about things like dreadful Pentium assembler but
it really isn't very true when talking about Forth, and
Forth chips, and the sort of things that I have been working
with much of the time for the last fifteen years.
> Maintenance is one of the most demanding
> questions of our time. The market is changing rapidly, so are
> applications. Reengineering unmaintainable code and rebuilding it is
> extremely expensive (Bell labs => software decay). Writing unreadable
> code (that you assumed I did)
Where did that come from? We have had no discussion of unreadable
code other than your statement that you try to create job security
by writing code that no one else can understand.
> is shooting in your own leg. Code is
> like a shark: it has to move or it dies.
You have got the HR tunes down pretty well. The market is a
changin, quality is the most important thing, we do our programming
in such a way as to maximize the utilization of the potential of
our employees to to achieve the highest quality. (ie. we make
our employees spend 90% of the time in meetings listening to
nonsense like these between the 10% of the time that they get
to do data entry or word processing.)
> > My original objection was only to your denying that there is room
> > for fast or compact Forths now that speed simply doesn't matter.
> > Now that you have been coaxed into reversing your position on
> > that I see no further reason to comment on your opinions.
> No, I haven't changed my opinion, see above.
You are still insisting that 'speed is not important.' Sad,
very sad. Very very sad. But not uncharacteristic of the
way people have been programmed to want to be taken in by
consumer computing conditioning.
> I just took the reverse
> side of the overall opinion here that small and fast is the only way
> to go and everything else is not worth mentioning.
Did you say, in some cases such as data entry and word procesing,
speed is not important? Did you say speed is not important period?
Face it, you were wrong. Now you are in full retreat but calling
it a strategic regrouping. You are not calling it a retreat because
you are insisting that you were not wrong. But you did have to
retreat whatever you wish to call it.
> We see ourselves
> still too much as the extreme elite of programmers (hey, who didn't
> write his own pet Forth compiler over here?
We? Most people start out as application programmers. Someone else
does the design and assigns them their task. As they learn more
they sometimes advance from applications programming to systems
programming. This is more demanding, speed is sometimes important,
and the problems tend to be more complex.
As they learn more sometimes they advance to analysts. Now they can
analyze systems, design and specify systems, and implement them or
hand the coding to junior systems programmer. Some will advance
to senior systems analysts with more complex and demanding problems
to deal with. There are many such jobs and titles in very large
companies.
Do senior systems analysts with twenty or thirty years experience
consider themselves more advance than the larger numbers of
entry level programmers, application programmers, batch programmers
etc.? Sure. This is quite natural. Does a professor consider
themselves more advanced in a given field than a freshman taking
their first course in a given subject? I hope so. There is
nothing wrong with recognizing that there are entry level
people and top level people. There is no shame in that.
Writing a pet Forth compiler hardly makes anyone an expert of
an member of the programming elite. However some people who have
paid their dues to become top level programmers have also
written a Forth compiler.
It may bother entry level programmers that there are programmers
who have more experience and know more than they do. And they
sometimes feel inadequate when comparing their own skills to
these people. Since they can't do the more complex things
they tend to dismiss them as not important. They can't write
fast programs so they declare, speed isn't important. And
it isn't to them so they declare that more experienced
programmers are just eating sour grapes.
> Try comp.lang.c for that
> matter) and still wonder why Forth remains so obscure.
I am missing your point. You want me to read comp.lang.c.
Why should I read c.l.c? Other than learn that there are
some people there who don't care about non-trivial things
and declare that speed is not important to them? Or will
I see that some people there make the mistake of simply
saying 'speed is not important' or something like that?
Sorry but I don't see what is to be gained by 'trying'
comp.lang.c. I guess you think I will learn 'why'
Forth is so obscure to C programmers. Hey, I already
know that one!
> "If your screen
> goes black and your keyboard freezes, you made an error.
> So don't do it".
If you say, 'speed isn't important' you made an error.
So don't do it!
> I see too often that we're like a bunch of custom powercar builders
> over here, racing the circuit with low weight, massive V12 engine cars
> and wonder why there are so few families using it to do shopping.
No one who owns a racecar with a V12 engine wonders why there are
so few families using them to go shopping. Only someone who knows
absolutely nothing about racecars with V12 engines could ever
think anything that dumb.
> Is
> shopping trivial? May be, but it makes a hell of a lot more sense in
> everyday life than making laps around the track.
People who drive racecars to go shopping do it because it is fun
and they can afford it. They know that not everyone can afford
a racecar or could afford to drive it on the street for fun or
to go shopping. But they are never going to wonder why soccer
moms don't pick up the team in a one seat sports prototype of
street legal formula car.
But some people do enjoy owning a racecar and driving it to
the store. (There are actually quite a few here in Northern
California where there are a lot of pretty affluent people.)
And sometimes the people who have to drive slower and more
mundane transportation don't like it that some people have
more exciting rides.
We see the same thing in computing. Most people must get
economy cars, sedans, and SUV. Some people who can afford
cars that are more fun, cars where speed is important or
where luxury is important, or both, or where some feature
that isn't there in the commodity consumer cars is available.
There are people who are happy to drive a Yugo and who will
say that a Yugo should be good enough for everyone. They will
say that real people can't afford a Ferrari or the insurance
or the maintenance. And they would be right. And with a
sour grapes tone they may say, speed isn't important anyway.
(nor is style or fun if you can't afford it.)
They need a Yugo to sort their 650 data items to the local
store and don't see that anyone else really ever needs
anything more than their cardboard Yugoscript Wagon.
> I love this language. I want to see it used.
I enjoy seeing it used by people who find it useful. I don't
like seeing it abused in the name of wanting to see it used more.
> People at work wonder why
> I'm able to make these conversion programs so quickly and are even
> more amazed when I show them I did it in a handful of lines where they
> need pages of visual basic. For many, it is their first encounter with
> forth..
That's nice.
> I love this language. I don't want to see it die..
If it is going to die in the near future I think the thing
that will have killed it will be the effort to promote it
as yet another inefficient scripting language instead of as
the smallest efficient systems language.
Scripting has it's place, but when the scripters start claiming
that speed is simply not important then Forth's vital signs
are in danger. Forth has dangerously low blood pressure? Bring
in the leaches and drain away more of its blood, that will
help. It's immenent death will make it more popular with
the people who have been claiming that it was dead for years.
Best Wishes
Jeff Fox
> My first database application was written in ZX-Basic and took 10
> hours to sort 650 entries. Z80 assembler did it in two minutes.
> According to some calculations I made this weekend semi compiled 4tH
> would do it in less than 10 seconds (conservative estimate on a 600
> MHZ PIII).
You have only seen a speedup of 12x since the days when you were
using a Z80? Yikes! I guess you are one of those people who are
happy to live with the kind of computer performance that people
were getting in the 1980s. I guess that is a consequence of
dealing with the new popular yet incredibly inefficient scripting
environments. People can return to the performance levels of
twenty years ago. It helps sell more computers and more software
but I do pitty the consumers who think of it as state of the art
progress. ;-)
If you live with 1980s type computer performance on your 21st
century computers, ie. speed is non-existent, then you might
get the impression that is must not be important. ;-)
Want to race to the grocery store?
Richard Owlett
> Richard Owlett wrote:
>
>>The group I was thinking of joining had two levels of particiapation:
>>1. a mailing list with send and recieve priveedges
>>2. a file download area
>>
>>To participate in the first, only a valid email address was required.
>>
>>To participate in the second a rather detailed form was presented. Among
>>other items it requested physical address, age, gender, and income
>>level. I balked at that.
>
>
> Yes, they may have spaces for all that on the form, but do they
> *require* that you supply that info? To sign up for a lot of things on
> Yahoo! they ask for a lot of info, but little of it is required, you can
> just leave it blank. Was that the case here?
>
Possibly.
"red flags" were raised just by them requesting VERY personal data
[without apparent justification] in the first place.
It went from "uneasy feeling" to "take shelter immediately" when they
failed to respond to *EITHER* my email or telephone request for
clarification.
Two personal quirks are also involved:
1. I do not wish to experiment to determine delineation of "what is
requested" from "what is required". If there is a difference, I presume
nefarious motives.
2. If asked for information, I'll respond truthfully
[ as in the truth
the whole truth
nothing but the truth ]
or not at all. It is a matter of personal ethics.
I will reiterate.
If anyone has an "in" with YAHOO! corporate, feel free to forward my
comments to them.
I think they have a PR problem.
Unless my DIM view of their apparent (lack of) ethics is correct.
rickman
>
> Possibly.
>
> "red flags" were raised just by them requesting VERY personal data
> [without apparent justification] in the first place.
>
> It went from "uneasy feeling" to "take shelter immediately" when they
> failed to respond to *EITHER* my email or telephone request for
> clarification.
>
> Two personal quirks are also involved:
> 1. I do not wish to experiment to determine delineation of "what is
> requested" from "what is required". If there is a difference, I presume
> nefarious motives.
> 2. If asked for information, I'll respond truthfully
> [ as in the truth
> the whole truth
> nothing but the truth ]
> or not at all. It is a matter of personal ethics.
>
> I will reiterate.
> If anyone has an "in" with YAHOO! corporate, feel free to forward my
> comments to them.
> I think they have a PR problem.
> Unless my DIM view of their apparent (lack of) ethics is correct.
I don't want to make a big deal of this, but there are not many web
sites that provide the sort of services that Yahoo does without at least
*asking* for information on you. That is how they finance the web
sites, by collecting information which is used to justify the money they
collect for the ads they display. I have looked into google adsense and
it is clear that they do a similar thing in order to charge the maximum
rates to their advertisers.
I don't see Yahoo as being "unethical" since they do tell you what they
can collect and what they do with it. If you are not comfortable with
that, then you might do well to avoid them. But I don't see that this
makes Yahoo a problem. Besides, their disclosure will cover everything
they are doing as well as anything they *might* consider doing. It is
mainly a bit of CYA.
Hans Bezemer
> twenty years ago. It helps sell more computers and more software
> but I do pitty the consumers who think of it as state of the art
> progress. ;-)
65K (including all goodies) and makes sub-1K executables. "Why?" they
ask me "You got gigabyte disks!!" I don't have a real answer to that
other than that it is fun.
> If you live with 1980s type computer performance on your 21st
> century computers, ie. speed is non-existent, then you might
> get the impression that is must not be important. ;-)
Most common programs have not speeded up significantly, although the
hardware has a massively increased capacity. Using an 80-ies program
will make you fly, but you soon find out that the learning curve is
higher, your productivity is lower, sharing information between
applications is harder. So there is an added quality there.
> Want to race to the grocery store?
I'd rather get there in one piece.. ;-)
Hans Bezemer
Hans Bezemer
> involve other definitions and one can almost never put a figure
> on something and nail it to the wall. No communication can take
> place between people when one insists that all definitons be
> giving in figures and nailed to a wall.
this. I even give lectures on Dutch colleges and universities on this
subject (what's why a lot of project go wrong). But when it gets to
technical matters it is of little help. Discussion-wise, I know the
trick, I'm not falling for it.
> You seem to be trying
> to reverse the situation to suggest that it was I who originally
> stated that speed is the most important thing in all cases. No
> I stated that there are embedded apps and demanding desktop apps
> that are apparently outside of your limited world where you declare
> that speed is simply not important.
area. It's normal for people to be defensive when their area of
expertise is losing significance. I can understand that.
> You haven't admitted to making the false statement, but now
> that you have agreed to agree with me you want to say that now
> I have agreed with you. Not exactly. You were wrong. You have
> apparently gotton off the narrow minded position that speed is
> simply not important and accepted that there are also many
> other cases, other than yours, where speed is important.
compactness, this group would better do to look around and see what is
going on outside. Forthers traditionally have to be dragged into the
real world, it seems. Forth will never be an operating system of
significance again, so we'd better build Forths that blend in well
with the outside world. My 4tH (although I'd never claim that should
be THE model for the rest of the Forth universe) blends in well with
Linux. Its (tiny) executables are interfaced with bin_fmtmisc so they
are executed like native ELF executables as far as the user is
concerned. It features files and pipes (much easier to handle than C).
Those are qualities other than speed and compactness and I think they
are important.
> I accepted from the start that speed was not important to some
> people. You reject the concept that speed was important to
> anyone by simply stating, speed is not important without
> any qualification.
further lose significance. When I talk to users they have only a
handfull applications that take a long time, like video rendering and
stuff. Even kernel compilation is not much of an issue anymore. In
other fields I rarely hear that speed is important. That was different
in the early days. Not only to users, but also to developers.
> I have been doing microprocessors since they were invented, desktop
> and embedded for thirty years. I have done mainframes and minis and
> full custom specialized ECL and CMOS computers, and parallel computer
> on various platforms. Most of the development tools and most of the
> programs are PC based these day and are very demanding.
I've done real life applications all my life, both for the government
and private sector. Interfacing systems, both technically and
logically, is a much hotter issue than speed. If we're lacking speed,
we take a faster machine. If we need more speed we're taking two
machines. With the price of current hardware, that is much cheaper
than having a specialist hacking on it for a few days. By redesigning
all this we're saving millions per year, apart from savings on the
payroll, have higher customer satisfaction and much faster and much
more accurate results. 'Speed' was not an issue. Time to market? Yes.
Flexibility? Yes. The number of programs that really require speed are
few, may be a few percent. Vital programs? Yes. But still: a few
percent.
> To those who solve problems and
> have to deal with problems and programs speed
> is important.
I've taken out all emotional and non-quantative adjectives. Now read
again. Simenon thought adjectives were bad for your writing anyway ;-)
> I realize that most people are not programmers and simply use
> whatever consumer software comes bundled on their computers.
What do you expect people to do? Write their own OS? Their own email
program? Their own wordprocessors? Their own compilers?
> And there are people who write scripts of one form or another.
> Often they don't care how fast they are. Sometimes they prefer
> them to be slower rather than faster. This limits how much work
> and how much thinking they have to do to get paid. The slower
> their software the less mental work they have to do to keep up.
Ok, I use a high speed, difficult compiler to do my work. That will
slow down my productivity. Since I'm doing the very same language, the
thinking work is not much different. In the end I produce an
executable that does the job in 0.01 seconds flat...
Now I'm using a much friendlier (semi) compiler. I am able to work
much faster. The executable does the job in 0.1 second...
This statement is nonsense and very offensive to many good and integer
programmers out there!!
> If I gave you a similar list of my experiences you would not
> a lot of custom work, designed to squeeze the last bit of speed
> out of demanding state of the art new hardware and software.
> You will see that my experience is not limited to data entry,
> batch processing, general purpose consumer programs and games.
> I have not limited my experience to non-demanding computing
> applications.
I did at least as much custom work than you did, designed to be
extendable, flexible and save the government and the companies I
worked for lots of money. They don't care whether a subsystem runs 1
second, 1 hour or one day because it is all within the requirements.
They do care that it is finished tomorrow, because then they have to
have the results. They don't care for a fast system that runs 100
times as fast when you're finished the day AFTER tomorrow. Those are
real world requirements..
> It is clear from your background that speed is not important to
> you. For data entry and batch processing and word processing
> it really doesn't matter. For your games you probably prefer
> faster frame rates, more detail, more intelligent behavior
> by agents, etc. Or then again you might be into adventure
> games where you pick up the magic key under the magic mat
> and put it in your ear to gain magical powers. For that type
> of game speed is not going to be important, it will be a
> lot like data entry. I am beginning to get an impression of
> just how limited your experience has been.
I don't think so. When I tackle a problem, I tackle the organization,
the information flows, the architecture of the entire system, the
design of the subsystems and write all critical parts myself. I
haven't been buried into a machine register all my life. I don't have
the time for that. But I'm not afraid to write a program in assembler
if I really have to.
> Not everyone working with computers is
> mostly doing things like data entry.
Most people are. And they do an important job. I depend on their good
work and ideas and my job is to enable them to do their job well.
> Couldn't a minimum wage worker without a computer do it much much
> faster than that? 10 hours to sort 650 entries? You must be kidding.
> I mean I know a 1Mhz 8080 is pretty slow, but that is ridiculous.
> I guess there is no upper limit for how inefficient a program can be.
I don't say ZX-Basic was a speed monster (it was notoriously slow).
But 10 hours justified the added effort to do assembler. 2 minutes was
fast enough. May be by doing other sorts (it was a bubble sort) it
could have been done faster. But acceptable remains acceptable (time
to market). Case closed, customer happy.
> The number that a minimum wage employee can sort per minute has
> gone down too. So now a Pentium can actually sort faster than a
> human, impressive.
If 2 minutes were acceptable, 10 seconds would be more than
acceptable.
> I think that there is a common misconception in the above statement
> that exposes a false assumption. People often say what you said, but
> it suggests that there is 'an assembler' that can be compared to
> the ever popular higher level languages. But the fact is that there
> is not an assembler. There are as many assemblers as there are
> processor designs. (more if you count implementations rather than
> CPU types.)
Who uses assembler nowadays? Must really be in the promille range!
Insignificant.
> You have got the HR tunes down pretty well. The market is a
> changin, quality is the most important thing, we do our programming
> in such a way as to maximize the utilization of the potential of
> our employees to to achieve the highest quality. (ie. we make
> our employees spend 90% of the time in meetings listening to
> nonsense like these between the 10% of the time that they get
> to do data entry or word processing.)
I do meetings without transcriptions within 30 minutes. My guys do
more than 3 minutes of data processing. They do things no computer may
do, no matter how much cycles you throw at it. Computers are fast,
accurate but don't handle communication and exceptions very well.
People are slow, inaccurate, but very good at handling communications
and exceptions. One should realize that.
> Face it, you were wrong. Now you are in full retreat but calling
> it a strategic regrouping. You are not calling it a retreat because
> you are insisting that you were not wrong. But you did have to
> retreat whatever you wish to call it.
I don't see that at all. Processing speed is not on the agenda of most
companies. They have to tackle other problems. Iron is cheap. Since
you have worked all your life in a highly specialized niche market,
you have obviously lost the big picture. I can't help that, I'm sorry.
> We? Most people start out as application programmers. Someone else
> does the design and assigns them their task. As they learn more
> they sometimes advance from applications programming to systems
> programming. This is more demanding, speed is sometimes important,
> and the problems tend to be more complex.
>
> As they learn more sometimes they advance to analysts. Now they can
> analyze systems, design and specify systems, and implement them or
> hand the coding to junior systems programmer. Some will advance
> to senior systems analysts with more complex and demanding problems
> to deal with. There are many such jobs and titles in very large
> companies.
>
> Do senior systems analysts with twenty or thirty years experience
> consider themselves more advance than the larger numbers of
> entry level programmers, application programmers, batch programmers
> etc.? Sure. This is quite natural. Does a professor consider
> themselves more advanced in a given field than a freshman taking
> their first course in a given subject? I hope so. There is
> nothing wrong with recognizing that there are entry level
> people and top level people. There is no shame in that.
Most problems do come from that kind of organization. I've been an
analist/programmer, analist and architect. The chain
specifications-design-program is fundamentally flawed, because of the
subjectivity of interviews, interpretation, etc. That is why Xtreme
programming emerged. The method I designed and use is massively
parallel development with weak binding between the modules. I've been
able to solve 3 million dollar failed projects by this technique,
consuming only 5% of the original out-of-pocket costs. This is
dinosaur computer science..!
BTW, by not taking a more humble attitude, you're incapable of
learning anything. I never accept an expert just because he's an
expert. Convince me! I don't want the people I work with to swallow
anything I say, just because I say it. Attack me, find the flaws in my
reasoning! Prove it to me in a scientifically accepted way
(quantative). If I win a debate, I'm just happy with myself. If I lose
a debate, I've learned something. I find the latter more important.
> Writing a pet Forth compiler hardly makes anyone an expert of
> an member of the programming elite. However some people who have
> paid their dues to become top level programmers have also
> written a Forth compiler.
I've helped several beginning Forth users who complained to me that
c.l.f was so elite. If you're a nice, friendly, modest bunch of guys I
do apologize to you all..
> It may bother entry level programmers that there are programmers
> who have more experience and know more than they do. And they
> sometimes feel inadequate when comparing their own skills to
> these people. Since they can't do the more complex things
> they tend to dismiss them as not important. They can't write
> fast programs so they declare, speed isn't important. And
> it isn't to them so they declare that more experienced
> programmers are just eating sour grapes.
I'm glad you're so happy with yourself. ;-)
> No one who owns a racecar with a V12 engine wonders why there are
> so few families using them to go shopping. Only someone who knows
> absolutely nothing about racecars with V12 engines could ever
> think anything that dumb.
Might it be that traditionally, those cars have only two seats and
very little storage room which makes them not quite suitable to do
shopping?
> People who drive racecars to go shopping do it because it is fun
> and they can afford it.
No real life application, I might say. Fun cars are fun. Commodity
cars do shopping. Fun applications are only for those who can afford
them. Most companies are there not just 'for fun', but to make a buck
and take care of their shareholders.
> I enjoy seeing it used by people who find it useful. I don't
> like seeing it abused in the name of wanting to see it used more.
I has been abused enough by people who have too high an opinion of
themselves. In order to teach, it helps to be humble and understanding
and have an eye for the hidden message in a question (I was and am a
teacher too, you know). Pupils are not there to highten your status or
stike your ego. You are there to teach them what they need to know.
And you have to find our their (individual) needs. Listening is more
important than talking..
Hans
Jeff Fox
> People around me declare me crazy when they see my compiler is only
> 65K (including all goodies) and makes sub-1K executables. "Why?" they
> ask me "You got gigabyte disks!!" I don't have a real answer to that
> other than that it is fun.
I won't call you crazy, but I will say that you big compiler
doesn't impress me or worry me. It sounds pretty average. Tell
me when you get your compiler down to 1K and I will be interested.
> > Want to race to the grocery store?
> I'd rather get there in one piece.. ;-)
Getting there in one piece is important. That requires some
skill at driving and some luck. If you worry that you couldn't
drive safely to the store then don't do it. If you were concerned
that I might run you off the road or something don't my strategy
would be to get you to dissapear in my rear view mirror. I can
barely see you in that rear view mirror anyway anymore, what
should I have expect from someone who whom speed is simply not
important? I'll watch out for you on my way back.
Best Wishes
Jeff Fox
> f...@ultratechnology.com (Jeff Fox) wrote in message news:<4fbeeb5a.04101...@posting.google.com>...
> > han...@bigfoot.com (Hans Bezemer) wrote in message news:<eaef3280.0410...@posting.google.com>...
> > The nature of natural language is that definitions of words
> > involve other definitions and one can almost never put a figure
> > on something and nail it to the wall. No communication can take
> > place between people when one insists that all definitons be
> > giving in figures and nailed to a wall.
> I know my Wittgenstein and I do have a girlfriend, so I am aware of
> this. I even give lectures on Dutch colleges and universities on this
> subject (what's why a lot of project go wrong). But when it gets to
> technical matters it is of little help. Discussion-wise, I know the
> trick, I'm not falling for it.
Fine. You introduced the 'trick' of demanding definitions in figures
and nailed to a wall. Thanks for not falling for the trick.
> > You seem to be trying
> > to reverse the situation to suggest that it was I who originally
> > stated that speed is the most important thing in all cases. No
> > I stated that there are embedded apps and demanding desktop apps
> > that are apparently outside of your limited world where you declare
> > that speed is simply not important.
> Which is a pretty specialized area. It used to cover a much bigger
> area. It's normal for people to be defensive when their area of
> expertise is losing significance. I can understand that.
You are saying that you are defensive because your area of
expertise is losing signifcance? I don't follow since you talked
about the growing use of scripting.
Certainly you could not mean that the systems that support and
make possible the trivial scripting layers are somehow what are
losing their significance. That would ignore the reality that
these thin scripting environments are simply a top layer on
such systems and are completely and utterly dependent on them.
The scripts are the frosting on the cake, but the significant
thing is of course the cake beneath. The frosting might be
insignificant and we call the whole thing cake (with frosting)
not frosting (with cake.)
So if it isn't scripting that is losing signifcance to you,
and it obviously isn't the required supporting systems upon
which scripting is entirely and utterly dependent I wonder
what else you might be talking about that is losing
significance.
> > You haven't admitted to making the false statement, but now
> > that you have agreed to agree with me you want to say that now
> > I have agreed with you. Not exactly. You were wrong. You have
> > apparently gotton off the narrow minded position that speed is
> > simply not important and accepted that there are also many
> > other cases, other than yours, where speed is important.
> And my statement was that instead of focussing on items like speed and
> compactness, this group would better do to look around and see what is
> going on outside. Forthers traditionally have to be dragged into the
Forth programmers were in the real world and were not dragged there
by anyone. The folks who arrived late found Forth being used in
real world applications more than 30 years ago.
No one dragged Forth programmers into any 'real' world. Sometimes
we take trip into concepts and practices from the past, like batch
processing and script toppings, to see how little progress has
been made there and how we can bring modern concepts back to these
folks living with concepts from the past. And it is funny too
that they sometimes think that doing batch is a new thing and
the wave of the future.
> real world, it seems. Forth will never be an operating system of
> significance again,
Forth has always been an operating system of significance whenever
it needed to be. Significance there would mean that it does exactly
what it needs to do, it solves some signifiant problem.
If you mean that it will never be a Windows or Unix type OS then
of course you are right. It was never intended to be that. It never
wanted to be that. It will never be that. It is good that it will
never be that. It provides an alternative by not being that.
If 'significance' means bigger than Windows to you why would you
care? Windows is average. Forth is above average. Forth could
get a larger audience if it were made more average, but it will
never compete with OS like Windows. Nor should it.
This is especially important because from the alternate methodology
that Forth offers it is pretty obvious that things like the
Windows OS is a mistake. It is based on technically flawed but
brilliant marketing concepts. For those needing to get some
demanding technical work done we have alternatives that are
more technically oriented and less market oriented things.
> so we'd better build Forths that blend in well
> with the outside world.
Forth has always blended in well with the outside world by
filling a niche that otherwise would not be filled. I know
that some people hate that and want to see Forth get out of
its successful niche where it can be lost among the
plethera of scripting languages today.
Yes, it could be taken away from the world, removed from the
niche where it has been sucessful and contributed something
unique and special and it could be changed into yet another
inefficient scripting language to get lost in the crowd today
and literally get 'blended in' like everything else.
But I say, if people want that, just create you own Forth
script. Forth can exist alongside this homogenized Forth
script. Please, please, please, let's not replace Forth
with this Forth script. Forth is alive and well. Forth
script may or may not have bright future. Create Forth
script if you want, but lets not junk Forth for this
Forth script.
Forth was designed to escape the limitations of conventional
operating sytsems and languages that the languages that were
locked into those limitations. Forth was designed to escape
external OS and provide custom OS as needed. C was designed
to write a general purpose OS for minicomputers.
Forth script goes in the direction of C when it requires a
C based OS, and is really just providing a handle to get at
OS services that are there. It is pretty much the opposite
of what Forth was designed to be.
So let's call it Forth script, and not say that this
OS scripting mirror image of Forth should replace Forth.
If it wants to exist alongside and try to establish its
value in the world and establish a niche fine. Let it
prove itself as it is yet unproven.
Let's not throw out Forth for this unproven C-Forth
scipting hybrid quite yet. Let's not even advocate that
yet.
> My 4tH (although I'd never claim that should
> be THE model for the rest of the Forth universe) blends in well with
> Linux.
> Its (tiny) executables are interfaced with bin_fmtmisc so they
> are executed like native ELF executables as far as the user is
> concerned. It features files and pipes (much easier to handle than C).
> Those are qualities other than speed and compactness and I think they
> are important.
And in a system that is 99.99% C it makes sense that the thousands
of constraints imposed by that fact should be what is important there.
Of course Forth was designed to avoid all that altogether.
> I will rephrase that: speed is not important to most people and will
> further lose significance.
Sure it is. That is a marketing illusion. There is a require for
an underlying system with sufficient speed to support further layers
of inefficient scripting on top. The top layer provides the illusion
that speed is not important. It is the 99% of the code that this
code is dependent on where speed is important.
If speed were not important on any layer then the OS itself would
be written in Perl or some other script. Scripting is slow now but
being a trivial layer on a non-trivial system the speed of the
underlying system is hidden by the slowness of the scripting.
Speed is still important even it is hidden to the most nieve
user's who only see the top scripting layer and somehow get
the nieve and silly idea that speed simply isn't important.
Give them a system where everything is written in their
precious script, where nothing is efficient and it would be
so slow and so bloated that even they would have to agree
that it was completely useless. They would have to realize and
admit that speed was important. Until then they can pretend
that the scipting layer is all there is.
> When I talk to users they have only a
> handfull applications that take a long time, like video rendering and
> stuff. Even kernel compilation is not much of an issue anymore. In
> other fields I rarely hear that speed is important.
What they mean, is further speed is not important for what they
are doing. What they mean is that speed is absolutely essential
up to the point where they are satisfied and that further speed
is not important.
Reduce their whole application speed down to the level of common
scripting environments and they would complain bitterly that
the damn things were useless and would insist that speed is
really really really important.
Speed is not important to someone who thinks they already have
enough. Intelligence is not important to someone who thinks
that they already have enough.
Once someone has written a sufficient amount of fast code
on a system the scripters can come in and write their slow
code. Their slow code would be impossible without the fast
systems code that they script. Speed is essential to give
the illusion to these confused scripters that speed is
not important.
> That was different
> in the early days. Not only to users, but also to developers.
It has never changed. It was always the same. Computers had
limited speed. To do more sophisticated more advanced things
they needed more speed. With more speed they could do new
more demanding things. This will never change.
With more speed they could also do the same old things that
they did before but in a more runtime wasteful way. Speed
is essential to provide the environment where there is speed
to waste in the first place to give the poor scirpters the
illusion that speed simply isn't important at all.
How these scripters could really believe the abusd illusion
that speed simply isn't important is a testimony to how well
false ideas can be marketed today and it is testimony to
how little trainging we provide people today to do critical
thinking. The market sort of requires a large number of
clueless consumers who buy into these illusions.
But when the people who have bought these illusions try
to 'sell' them to the peole who did the work, who wrote the
relatively efficient code that made this marketing deception
that speed isn't important possible the people who know that
speed is ultimately important are amazed that consumers could
really be so nieve and so misguided about what they have
bought.
You can't sell the idea that speed isn't important to me
no matter how much you invested when you bought into it.
You were sold this idea because people who knew that it
wasn't true made it possible by writing systems that were
sufficiently fast to give the the false impresssion that
speed doesn't matter.
> > I have been doing microprocessors since they were invented, desktop
> > and embedded for thirty years. I have done mainframes and minis and
> > full custom specialized ECL and CMOS computers, and parallel computer
> > on various platforms. Most of the development tools and most of the
> > programs are PC based these day and are very demanding.
> I've done real life applications all my life,
You were born programming? You got the jump on me. Even though
I wasn't born programming like you, I have over fourty years
experience. More than most and all real life.
> both for the government and private sector.
Government usually wins in any meansure of waste an inefficiency
when compared to anything else. Some work in the private sector
can also be incredibly inefficient and wasteful.
When exchanging stories about who deals with the most waste
and inefficiency those working for government usually win. So
perspectives about how much waste is tolerable or even good
depend on a lot on the workplace culture. Government, companies
that have grown out of control, and scripting environments are
all examples of cultures where waste is expected and tolerated
to a degree that horrifies people in the 'real world' as you say.
> Interfacing systems, both technically and
> logically, is a much hotter issue than speed.
The systems could no exist except for the concern over the issue
of speed. I like cake with some frosting on it. You like
frosting and don't seem to realize that there is cake below it.
Speed is the hot issue, the frosting covers that up.
> If we're lacking speed, we take a faster machine.
Ie: speed is important. Speed is essential. Speed is assumed.
After that, waste is possible until speed becomes important
again.
> If we need more speed we're taking two machines.
Speed is important. You are now giving us more supporting
evidence of that. I wish you could see that.
But cost is usually also important. That's why people
generally will prefer to pay for one machine rather than
pay for two if the only difference is that two machines
lets them do the same job at twice the cost and half
the efficiency. Since speed and money can be exchanged,
speed is important as money is important.
> With the price of current hardware, that is much cheaper
> than having a specialist hacking on it for a few days.
Two computers programmed by a junior programmer might indeed
be cheaper in the short term than one computer programmed
by a more expensive more senior specialist. However in the
long run, with upgrades, maintenance, facility costs, power
costs etc. going for the higher quality in the first
place will often be justified.
The shortsightedness of focusing only on the costs today
rather than long term costs is the sort of thing that leads
management to make the mistake of throwing hardware at
inefficient and, in the short term, inexpensive software
solutions. In the long term quality may be a more
important factor. I can think of countless examples where
some manager thought they would save money going that way
but then they have to bring in the special anyway to clean
up the mess and do it right. They process ends up costing
more, taking longer, and being written of as another mistake.
But the holy grail to management is to replace skilled workers
with less skilled workers. They will make the same mistake
again and again, they rarely learn, they really want to find
a solution where unskilled scripting programmers can do for
them what traditionally cost more up from, work by more
skilled programmers. They have been trying to get all the
work done by less skilled employees and will no doubt keep
trying it and failing.
> By redesigning
> all this we're saving millions per year,
I have heard that before and seen the quartly figures given
to support it. And many times I have seen them come in afterward
and have to spend an extra fifty million to clean up the mess
once they realized that it was a short term patch that cost
more in the long run.
> apart from savings on the payroll,
They see savings in payroll in the short term. The is simply
because they thought they could scrimp and use unskilled rather
than skilled labor. They thought that programmers who only see
the top level illusion and think it is real could come up with
long term solutions.
> have higher customer satisfaction and much faster and much
> more accurate results.
This is absolutely true for things like providing some
scripting features for the complex systems that they have
built and paid for. It is the frosting that makes the cake
look good, and gives it that extra sweetness. And some fool
will always claim that there is no cake below the frosting
or that the cake isn't important. It just holds up the
frosting.
> 'Speed' was not an issue. Time to market? Yes.
For scripts yes. Who markets scripts? That is a very very
small market niche. The scipts are the frosting that help
the complex systems do what they have to do to create whatever
product it is that they are going to sell.
> Flexibility? Yes. The number of programs that really require speed are
> few, may be a few percent. Vital programs? Yes. But still: a few
> percent.
This is absolutely true about the 1% that forms the frosting.
Speed is not important there just as yeast was not needed in the
frosting. But without the yeast in the cake to make it rise,
without the relatively efficient systems software that make up
most of the reality of the cake there is no need for frosting.
If all you see is the frosting you may get the mistaken idea
that cake is not at all important in making a cake.
> > I realize that most people are not programmers and simply use
> > whatever consumer software comes bundled on their computers.
> What do you expect people to do?
Most people will be consumers. They will buy PCs like they buy
audio CD players and will use them in a similar way, to play
content that the device makes available. They will buy packaged
products and consume them.
I only expect programmers to program. That is a very small
percentage of PC consumers. If they are C programmers then
in most cases they will write C code that will run on their
C based OS. Some embedded programers will use a C based OS
and C compiler to write their own OS for their embedded
apps while others will use a canned OS.
Programmers are not your average computer consumers, they
have an interest in programming the things not just using
them to play content. Forth programmers will in some cases
write Forth to ride on top of foreign OS and in some cases
will write their OS as part of the Forth that they right.
Many Forth programmers will write the OS functions as needed.
This is the way Forth works in many cases. There is nothing
wrong with that.
Of course some Forth haters will twist this into an absurdism
and ask 'should all programmers have to write their own OS?"
which of course has nothing to do with the issue at hand.
> Write their own OS?
If that is their job of course. When it is a good thing
it is a good thing. That is Forth thinking. If people
choose Forth programming they have this option. It does
sometimes seem absurd to the incompetent who would never
ever consider doing such a thing.
> Their own email program?
Sure. If they are programmer they can program programs to
do what they want. If they want a custom email program they
can write one. I know a number of people who have done it.
There is nothing wrong with it. It's called programming.
> Their own wordprocessors?
Sure. If they are programmer they can program programs to
do what they want. If they want a custom word processor they
can write one. I know a number of people who have done it.
There is nothing wrong with it. It's called programming.
> Their own compilers?
Sure. If they are programmer they can program programs to
do what they want. If they want a custom compiler they
can write one. I know a number of people who have done it.
There is nothing wrong with it. It's called programming.
For people building new machines things like this are
part of the job.
I have this idea that programmers should be able to
program. Some programmers who have severely limited
programming skills, mostly cut and paste, seem to
recoil at the idea that a skilled programmer can
acutally write a program when they need to. This bothers
them, they see no need for competent programmers and
make light of programmers writing programs in the
real world, real programs, not just scipts.
> > And there are people who write scripts of one form or another.
> > Often they don't care how fast they are. Sometimes they prefer
> > them to be slower rather than faster. This limits how much work
> > and how much thinking they have to do to get paid. The slower
> > their software the less mental work they have to do to keep up.
> Ok, I use a high speed, difficult compiler to do my work. That will
> slow down my productivity. Since I'm doing the very same language, the
> thinking work is not much different. In the end I produce an
> executable that does the job in 0.01 seconds flat...
> Now I'm using a much friendlier (semi) compiler. I am able to work
> much faster. The executable does the job in 0.1 second...
> This statement is nonsense and very offensive to many good and integer
> programmers out there!!
It is? Why offend good programmers? I guess I miss your point,
what's your point.
> > If I gave you a similar list of my experiences you would not
> > a lot of custom work, designed to squeeze the last bit of speed
> > out of demanding state of the art new hardware and software.
> > You will see that my experience is not limited to data entry,
> > batch processing, general purpose consumer programs and games.
> > I have not limited my experience to non-demanding computing
> > applications.
> I did at least as much custom work than you did,
Well I wasn't born programming like you. But I also get the
impression that you might have done less that 40 years worth
even if you did start at birth.
> designed to be
> extendable, flexible and save the government and the companies I
> worked for lots of money. They don't care whether a subsystem runs 1
> second, 1 hour or one day because it is all within the requirements.
Someone should care. Those are our tax dollars. I care whether
the apps that I paid for run in one second or one day whether I
paid for persona work or paid for it with my tax dollars.
> They do care that it is finished tomorrow, because then they have to
> have the results.
Of course the nature of scripting work is that the computation is
trivial, the system being scripted does almost all the work. Since
the system is likely to be relatively efficient, inefficiency in
the trivial scripting layer is not an issue. The issue is getting
the scripts written quickly.
God help us when people think the scipts are the only important
thing. The frosting requires the cake. Speed is required below
the frosting.
> They don't care for a fast system that runs 100
> times as fast when you're finished the day AFTER tomorrow.
Often I found people wanted results yesterday, not the
day AFTER tomorrow. Tempis fugit.
> Those are real world requirements..
Sure, there have always been batch programming types who
work on things that don't have to be done right away or
quickly. The real world does include these sorts of things
in addition to all the demanding computations that have
tighter requirements than someday.
> > It is clear from your background that speed is not important to
> > you. For data entry and batch processing and word processing
> > it really doesn't matter. For your games you probably prefer
> > faster frame rates, more detail, more intelligent behavior
> > by agents, etc. Or then again you might be into adventure
> > games where you pick up the magic key under the magic mat
> > and put it in your ear to gain magical powers. For that type
> > of game speed is not going to be important, it will be a
> > lot like data entry. I am beginning to get an impression of
> > just how limited your experience has been.
> I don't think so. When I tackle a problem, I tackle the organization,
> the information flows, the architecture of the entire system, the
> design of the subsystems and write all critical parts myself.
OK.
> I haven't been buried into a machine register all my life.
Huh? What's that? Are you just a program and not a human
being? You can fit in a computer register? Imagine that.
> I don't have the time for that. But I'm not afraid to write a
> program in assembler if I really have to.
People who are too impatient to do non-trivial programming
can sometimes find a niche as scripters. People who descibe
programming as 'I run to my library and cut out something
and paste it in. Job done and I didn't even find myself
getting bored with details.'
> > Not everyone working with computers is
> > mostly doing things like data entry.
> Most people are. And they do an important job.
Yes. They have a rather mindless repedative job that will
probably be replace by a computer as we automate. But until
then we need a pool of unskilled labor to do it. Unlike
most programmers, but like some script programmers they
will never feel that speed is an issue. As long as the
computer can keep up with their typing speed will not
seem important to them.
> I depend on their good
> work and ideas and my job is to enable them to do their job well.
Sure. I have supported large word processing and data entry
staffs before by selecting their systems, getting them running
and maintaining them so that they can enter their data. But
I have also at times written programs that replaced them.
This is the sort of things that programmers do and one of
the things that distinguishes them from data entry types.
Some programmers are close to data entry than others.
> Who uses assembler nowadays?
Lots of programmers still use assembly. It is still used
in embedded systems. It is still used by compiler writers.
We use it in chip design. Demanding programmers still resort
to it when needed.
And of course there are those of use who get all the
benefits of assembler and Forth at the same time. The
assembler is Forth so it is not complex and obscure like
it is with ugly processors like Pentium. So the antagonism
that people normally have for assembler is misplaced. There
is still the opportunity for people who are antagonistic
toward Forth to have a complaint. But we enjoy it.
> > Face it, you were wrong. Now you are in full retreat but calling
> > it a strategic regrouping. You are not calling it a retreat because
> > you are insisting that you were not wrong. But you did have to
> > retreat whatever you wish to call it.
> I don't see that at all.
OK. Don't face it if you prefer that. You were still wrong whether
you face it or not. You can be wrong again by not facing it, but
if once was ok with you more will probably be ok too.
> Processing speed is not on the agenda of most companies.
Nonsense. Processing speed is an issue for every computer
that they buy. Everyone knows this. If they can get a 3G
machine for the same cost as a 100Mhz machine they will
make the decision to go with higher processing speed because
the amount the computer can do will depend entirely on this.
> They have to tackle other problems. Iron is cheap. Since
> you have worked all your life in a highly specialized niche market,
> you have obviously lost the big picture. I can't help that, I'm sorry.
Highly specialize niche market? You didn't bother to read my
background did you? I have a very broad background with a much
wider range of experience than most people I know who work in
computing. I have specialize for the last fifteen years in Forth
computers, but that means I have also been deeply involved in
projects like internet appliances that depend entirely on a
picture much bigger than the PC picture.
My problem, quite frankly, is that most people cannot see the
big picture.
> BTW, by not taking a more humble attitude, you're incapable of
> learning anything.
Heal thy self.
> I never accept an expert just because he's an
> expert. Convince me! I don't want the people I work with to swallow
> anything I say, just because I say it. Attack me, find the flaws in my
> reasoning! Prove it to me in a scientifically accepted way
> (quantative). If I win a debate, I'm just happy with myself. If I lose
> a debate, I've learned something. I find the latter more important.
I have not attacked you. I have attacked some really stupid
arguments such as that speed isn't important in computing. ;-)
If you could come up with a topic, rather than rambling quite
so much a debate would be interesting. What should be topic?
Resolution: Speed is simply not important in computing.
You can take the affirmative and present the arguements in favor
of your proposition. Any sane person should be able to take the
negative and win the debate easily. A skilled debator should
not be required. The proposition is so blatently false that
any but the worst debators should be able to prove it false.
> I've helped several beginning Forth users who complained to me that
> c.l.f was so elite. If you're a nice, friendly, modest bunch of guys I
> do apologize to you all..
Resolution: Forth is for elitists not below average programmers.
Forth needs to change and be replaced by Forth script because
scripting is more popular as we get more below people with
below average intelligence programming.
I saw a study recently of IQ in different professions. I was
disappointed that the average level of programmers has dropped
so much. If we are going to encourage so many below average
people to program we will have to change something to dumb
programming down to their level. This is the holy grail
of management.
> Might it be that traditionally, those cars have only two seats and
> very little storage room which makes them not quite suitable to do
> shopping?
Yes. And the average person can't afford to buy one. The can't afford
the insurance. They can't afford the maintenance. They also can't
fit much in the trunk when it is the size of a purse and they can't
pick up the kid's sports team and equipment.
Oh, yeah, and most people are not good enough drivers that they
could control the racecar, if they tried to drive one to the
supermarket the result would likely be tragedy. They need a
lower performance low cost transport.
The people who can afford such cars and who enjoy driving them to
the store to get a tiny bag of groceries know perfectly well why
most people are not. Your statement that people who drive racecars
to the supermarket don't understand why most people don't is as
dumb as your attempt to imply that people who do serious programmer
don't understand why everyone else doesn't.
Yes. And the average person can't afford to take the time
to do high quality computer programming. They use off the shelf
stuff someone else did. The can't afford performance quality.
They can't the other costs of highest quality and settle for
average.
Oh, yeah, and most people are not good enough programmers that they
could program a high quality solution, if they tried to the result
would likely be tragedy. If they can program at all they need a
low performance model with lots of training wheels and rubber
bumpers.
> > I enjoy seeing it used by people who find it useful. I don't
> > like seeing it abused in the name of wanting to see it used more.
If you defend ineptitude, stupidity, and waste you can call it
defending the average guy. If someone says that there will also
always be a need for quality you can call that elitism. But
it will still be true that there will always be a need for some
top quality stuff. Those who can't play may consider it sour
grapes.
Don't worry. All the scripting programmers and data entry clerks
are not in danger of losing their jobs soon.
> I has been abused enough by people who have too high an opinion of
> themselves. In order to teach, it helps to be humble and understanding
In order to teach others to reach their highest potential one has
to try to set an example of trying to reach the highest potential
oneself. For those striving to reach average this must be a bitter
pill since only half of them will ever even reach average.
Still as Mr. Moore says, there should always be a need for some
people to strive for excellence even if the majority resent anyone
above average. We need to encourage those with the potential for
excellence to strive for it. This has been the niche that Forth
has filled.
I just had a great idea. Let's replace all that with Forth
Script for Dummies so that we are careful not to offend anyone
who might have below average intelligence or abilities, hey
that's half the population!
I will let other people experiment with making Forth popular
with below average people. I will concentrate on the top few
percent who can benefit from things Mr. Moore has shown far
more than the average guy who will never be able to get it.
> and have an eye for the hidden message in a question (I was and am a
> teacher too, you know). Pupils are not there to highten your status or
> stike your ego. You are there to teach them what they need to know.
> And you have to find our their (individual) needs. Listening is more
> important than talking..
Sometimes when someone wants to learn something they ask the
nearest person. Sometimes they google the internet. Sometimes
they go to the local bookstore and pick one of the hundreds of
books on the subject.
Sometimes they do their research and try to determine who are the
top people in the world in the field. And sometimes they they travel
halfway around the world and devote a decade or two to studying
the fine points of the art from the master who's expertise and
personalaity best match their own personality and interest. This
is a very long tradition.
Some people suffer to study from the most advanced most demanding
master that they can find. Some people ask anyone and accept whatever
answer they get assuming that the person knew more than they did.
Sometimes they then declare themselves a master and begin teaching
others. On the internet it is almost always the latter.
So in things like Forth you get a lot of the blind leading the
blind. You get people who are taught be teachers that were taught
be teachers who were taught be teachers who were so far removed
from the original teaching that they only get a tiny percentage
of the teaching, or something completely different, but called
by the same name by the teacher. So in a place like usenet if
you discuss a topic like Forth you will mostly get blind leading
the blind in the dark and insisting that there are no sighted
people out the period.
Anyone paying their dues to get real training and anyone taking
that training seriously is likely to called arrogant or elitest.
Some blind people think life would be easier if everyone else
was blink like them. They may resent sighted people, but in
reality sighted people make their lives a lot easier.
So people who really want to learn or see something will not
be easy to understand by the average person who has had their creativity
sufficiently squelched. The average person has a hard time understanding
either the level of interst or thelevel of sacrafice or the level
involvement in anything that serious people have. They see this level
of commitment to an art or science as obsession. And compared to the
average person it is obsession. The top people in any field are going
to be obsessed with their perfection of their art. Call them
arrogant elistist for striving for quality if that bothers you.
They are very different than the people who dabble in many many
different fields or interests but don't get really deep into any
of them. They often devote their entire lives to their arts
and spend most of their lives getting in as deep as possible to
their arts.
Average people don't understand these creative people. But they
do appreciate the work that they do. Most people realize that
the significant works in science or art that make their lives
as enjoyable as they are come from these creative, obsessed,
people who strive for perfection of their art.
Of course some people also resent that there are some people
striving for perfection and willing to sacrafice lots of things
that are important to average people in exchange for the chance
to perfect the art that they love. They enjoy the art, music,
literature and inventions that the creative people come up
with. But they may resent these people and be hostile towards
them.
And for every creative person there will be an army of people
trying to convince them that quality isn't important, that they
should not devote themselves to the art that they love quite
so much. For every creative person there will be an army
of people who are trapped in borring lives where there is no
need or opportunity for creativity or passion for perfection.
These people often resent the creative types because they
envy them. They don't appreciate that envy might not be
appropriate because they may not appreciate just how many
sacrifices these people do make.
One of the things that we have to deal with in this culture
is the pressure to comform, to not be creative, to not
strive for perfection or achieve it. And those who choose
creative paths know that they should expect to be called
arrogant elitists and other names meant to attach some
negative connotation to high quality. They expect to
be called names like arrogant and elitist by those
championing the opposite of quality, it goes with the
territory.
These people tend to ignore this sort of constant pressure
all their lives and just focus on what they enjoy, trying
to perfect their arts. Some of them even go on to teach
others who are also obsessed with perfection. Part of this
is to repay the kindness of the person who taught them the
art. There will always be some small number of people who
care about such things.
Best Wishes
Andrew made a comment the other day and I was very tempted
to reply with, "You sound like an arrogant elitist. Well done."
I should probably drop out of this thread. I seems that you
are determined to dig in and defend such ideas a speed isn't
important in computing, and that high quality is an insult
to average people.
Bernd Paysan
> And of course there are those of use who get all the
> benefits of assembler and Forth at the same time. The
> assembler is Forth so it is not complex and obscure like
> it is with ugly processors like Pentium.
It's far worse on 8 bit processors (8051, PIC, whatever). The Pentium
assembler is comfortable compared to CPUs that are the same size as a
Forth processor (but much slower).
> So the antagonism
> that people normally have for assembler is misplaced. There
> is still the opportunity for people who are antagonistic
> toward Forth to have a complaint. But we enjoy it.
Well, I don't. I feel the urge to bang my head into the wall when
someone tells me that he knows he needs assembly language (due to
memory constraints), and that he must hire 10 people or so for 8k words
of assembly program (considering the two years development time, that's
two lines per day, one in the morning, the other in the afternoon ;-),
but shuns at Forth, where one person could do that job, probably within
half or a quarter of the memory, in a way that can be audited for
security (it was a wireless key project), and I don't want to talk
about the time it would have taken without crying loud ;-). Due to the
10 people his budget was so constrained that there was hardly anything
left for the hardware, so we didn't do it for him.
It was probably all empire-building. The programmers would be under his
control, while the hardware was contract work, and in no way the
hardware costs would be accounted to his management capabilities. He
also had the primary requirement for managements: ignorance. If
ignorance wasn't so widespread, I'd say it is a necessary element to
become manager. Maybe it is even though.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Jeff Fox
> Jeff Fox wrote:
> > And of course there are those of use who get all the
> > benefits of assembler and Forth at the same time. The
> > assembler is Forth so it is not complex and obscure like
> > it is with ugly processors like Pentium.
>
> It's far worse on 8 bit processors (8051, PIC, whatever). The Pentium
> assembler is comfortable compared to CPUs that are the same size as a
> Forth processor (but much slower).
I can't really say that I am an expert in 8051, PIC, or Pentium
assembler. Far from it. I think I know what you mean that writing
in a subset of Pentium assembler lets one compose reasonable code
fairly easily while trying to struggle with the limitations of
peculiar and resource constrained processors can make doing things
that seem like they should be easy rather convoluted.
But the other side of that is that getting a handle on all the
Pentium opcodes, modes of operation, and the subtilies of pipeline
stalls with particular instruction sequences seems to be something
that no one has a handle on. People who look like experts like
Marcel say that he really has to benchmark code to see if one
sequence is better than another.
But I know what you mean. Small processors come in some very
clunky variations and may make coding in assembler quite troublesome.
But many people say the liked the assembler of certain processors
and enjoyed coding in them. But you don't hear much of that now
that coding in assembler has been complicated and better alternatives
exist.
> > So the antagonism
> > that people normally have for assembler is misplaced. There
> > is still the opportunity for people who are antagonistic
> > toward Forth to have a complaint. But we enjoy it.
>
> Well, I don't.
Then I won't include you in the we that I was talking about.
> I feel the urge to bang my head into the wall when
> someone tells me that he knows he needs assembly language (due to
> memory constraints), and that he must hire 10 people or so for 8k words
> of assembly program (considering the two years development time, that's
> two lines per day, one in the morning, the other in the afternoon ;-),
> but shuns at Forth, where one person could do that job, probably within
> half or a quarter of the memory, in a way that can be audited for
> security (it was a wireless key project), and I don't want to talk
> about the time it would have taken without crying loud ;-). Due to the
> 10 people his budget was so constrained that there was hardly anything
> left for the hardware, so we didn't do it for him.
Yeah well if that's what assembler means where you work you have
my most heartfelt sympathy. That sounds similar to a story Guy told
not too long ago about some manager prefering to have a bunch of
assembler programmers who could inflate his budget without getting
too much work done.
> It was probably all empire-building. The programmers would be under his
> control, while the hardware was contract work, and in no way the
> hardware costs would be accounted to his management capabilities. He
> also had the primary requirement for managements: ignorance. If
> ignorance wasn't so widespread, I'd say it is a necessary element to
> become manager. Maybe it is even though.
The dynamics of power shifting that occur all the time as projects,
people, and proceedures change can be very subtile. We tend to call
all of that empire building, but often it is just people covering
themselves from perceived risks or being stuck in a rut and not
even being aware that they are stuck in a rut.
As for theories explaining the problem of inept management I
always liked the Peter Principle. People tend to get promoted
up to their level of incompetence then they get stuck there.
Best Wishes
Hans Bezemer
> would be to get you to dissapear in my rear view mirror. I can
> barely see you in that rear view mirror anyway anymore, what
> should I have expect from someone who whom speed is simply not
> important? I'll watch out for you on my way back.
For reasons of safety that isn't a good strategy anyway. Remember what
Gorbatshov said during his visit in East Germany 1989: "Who gets there
too late, will be punished by life itself." Six weeks later, the wall
fell. I was in East Berlin at the time and I remember it well. In your
case, it is well worth contemplating..
Hans
Jeff Fox
> For reasons of safety that isn't a good strategy anyway. Remember what
> Gorbatshov said during his visit in East Germany 1989: "Who gets there
> too late, will be punished by life itself." Six weeks later, the wall
> fell. I was in East Berlin at the time and I remember it well. In your
> case, it is well worth contemplating..
Actually my driving strategy tends to be 'What's behind you is not
important.' I suppose if any of the cars in the rear view mirror
were trying to pass I would have to pay more attention to it but
as they generally just drop away I don't pay much attention to
the rear view mirror.
This is generally true regarding my view of technology too. I
don't sing the praises of try to promote batch processing as
the new wave of the future. Most people seem to move so slowly
and in regard to Forth most are still stuck in the 1970s and
1980s concepts of Forth. Most have not even considered let
alone adopted things that were innovations twenty years ago.
My 'problem' is that I like to move forward.
Some people just resent the people who drive racecars to the
grocery store. But more people give you thumbs up and cheers
as you drive by, kids shout in delight and point and ask if
it is a toy car. Most people think it is fun, but it seems
to bother certain people. I see much the same thing in
regard to omputing. Some people find efficient computing
interesting and fun, some find it threatening and a
terrible thing. I have heard all the reasons over and
over why clear thinking, and efficient practices are
bad, peole tend to be afraid that you are blowing the
whistle on them. Some are very much more touchy about
anyone blowing a whistle or even simply providing an
alternate example for comparison.
Don't worry. Data entry types and batch programmers are
not obsolete yet.
Best Wishes
Bill Spight
> Some people just resent the people who drive racecars to the
> grocery store. But more people give you thumbs up and cheers
> as you drive by
Or drive *into* the store, as a friend of mine accidentally did. ;-)
Best regards,
Bill
ebike
Version 0.80 (beta) of GraspForth has been posted to :
ftp://ftp.taygeta.com/pub/Forth/Compilers/native/misc/graspForth
It also has been listed on:
http://www.forth.org/compilers.html
Have fun,
Bernard Mentink
Bill McCarthy
> Version 0.80 (beta) of GraspForth has been posted to :
>
> ftp://ftp.taygeta.com/pub/Forth/Compilers/native/misc/graspForth
There appears to be a failure to communicate with GCC 3.2 (MinGW)
on XP Pro SP2. Simply typing `make` is rewarded with:
In file included from graspforth.c:26:
linux.h:9:21: termios.h: No such file or directory
In file included from graspforth.c:26:
linux.h: In function `init_keyboard':
linux.h:77: warning: implicit declaration of function `tcgetattr'
linux.h:78: `new_settings' has an incomplete type
linux.h:79: invalid use of undefined type `struct termios'
linux.h:79: `ICANON' undeclared (first use in this function)
linux.h:79: (Each undeclared identifier is reported only once
linux.h:79: for each function it appears in.)
linux.h:80: invalid use of undefined type `struct termios'
linux.h:80: `ECHO' undeclared (first use in this function)
linux.h:81: invalid use of undefined type `struct termios'
linux.h:81: `ISIG' undeclared (first use in this function)
linux.h:82: invalid use of undefined type `struct termios'
linux.h:82: `VMIN' undeclared (first use in this function)
linux.h:83: invalid use of undefined type `struct termios'
linux.h:83: `VTIME' undeclared (first use in this function)
linux.h:84: warning: implicit declaration of function `tcsetattr'
linux.h:84: `TCSANOW' undeclared (first use in this function)
linux.h: In function `close_keyboard':
linux.h:89: `TCSANOW' undeclared (first use in this function)
linux.h: In function `keyhit':
linux.h:99: invalid use of undefined type `struct termios'
linux.h:99: `VMIN' undeclared (first use in this function)
linux.h:100: `TCSANOW' undeclared (first use in this function)
linux.h:102: invalid use of undefined type `struct termios'
linux.h:131:7: warning: no newline at end of file
In file included from graspforth.c:27:
forthdef.h:320:1: warning: "NEXT" redefined
forthdef.h:120:1: warning: this is the location of the previous definition
forthdef.h:343:1: warning: "USER" redefined
forthdef.h:217:1: warning: this is the location of the previous definition
forthdef.h:347:1: warning: "UTYPE" redefined
forthdef.h:268:1: warning: this is the location of the previous definition
graspforth.c: In function `main':
This is followed by 2081 warnings of:
initialization makes integer from pointer without a cast
And 11 warnings of:
assignment makes integer from pointer without a cast
And 4 warnings of:
assignment makes pointer from integer without a cast
Followed by:
linux.h: At top level:
linux.h:13: storage size of `initial_settings' isn't known
linux.h:13: storage size of `new_settings' isn't known
make: *** [graspforth.o] Error 1
--
Best regards,
Bill
ebike
> on XP Pro SP2. Simply typing `make` is rewarded with:
>
> In file included from graspforth.c:26:
> linux.h:9:21: termios.h: No such file or directory
> In file included from graspforth.c:26:
This header is needed for the termios functions that I use, you will
need to find termios.h somewhere and make sure it is in the compiler's
include search path -Ipath etc.
> This is followed by 2081 warnings of:
>
> initialization makes integer from pointer without a cast
>
These are normal, a result of the way graspForth is made readable. (IE
If I had to cast every word it would be totally un-readable) I havn't
found a switch for gcc to turn these warnings off ... ;-)
> Followed by:
>
> linux.h: At top level:
> linux.h:13: storage size of `initial_settings' isn't known
> linux.h:13: storage size of `new_settings' isn't known
> make: *** [graspforth.o] Error 1
As above, need to have the termios functions available. I am not sure
what the lib is called (maybe libcurses?), and of course you need
termios.h. Did you install binutils ... maybe it is included with
those tools?
Sorry I can't be more helpful.
Cheers,
Bernard.
ebike
include this library and your include and lib search paths include
glibc.
What GCC tools are you using ... cygwin?
Cheers,
Bernard.
Bill McCarthy
> After investigation: termios is part of glibc. Make shure your tools
> include this library and your include and lib search paths include
> glibc.
I don't see glibc* or termios* on my system - XP Pro
with GCC.
> What GCC tools are you using ... cygwin?
As I said, it's MinGW - the native Windows version of
GCC.
CygWin is for Linux wantobes :-)
--
Best regards,
Bill
rickman
>
> > This is followed by 2081 warnings of:
> >
> > initialization makes integer from pointer without a cast
> >
>
> These are normal, a result of the way graspForth is made readable. (IE
> If I had to cast every word it would be totally un-readable) I havn't
> found a switch for gcc to turn these warnings off ... ;-)
Why would casting make code unreadable? Casting makes it clear what the
code is intended to do.
Bill McCarthy
> ebike wrote:
>>
>> > This is followed by 2081 warnings of:
>> >
>> > initialization makes integer from pointer without a cast
>> >
>>
>> These are normal, a result of the way graspForth is made readable. (IE
>> If I had to cast every word it would be totally un-readable) I havn't
>> found a switch for gcc to turn these warnings off ... ;-)
> Why would casting make code unreadable? Casting makes it clear what the
> code is intended to do.
Furthermore, if the cast is considered ugly, the
preprocessor can be used to define a prettier cast
proxy :-)
--
Best regards,
Bill
Metastabl
Thanks for posting this. I was able to get it to build on a Windows
2000 machine with cygwin installed and it seems to work.
For fun I tried on an iMac and ran into some problems as you might
expect. I think that the major problem is the lack of big endian
support that you mentioned in the README. The other problem was that I
had to give gcc the "-traditional-cpp" flag or it got confused with
the && labels as values notation. I only have gcc 3.1 on OS X, so
maybe this is a solved problem.
Thanks,
Keith
ebike
you are missing part of the tools. I have compiled with Cygwin no problem ..
You might need to talk to the MinGW folk.
Cheers,
Bernard.
ebike
> > If I had to cast every word it would be totally un-readable) I havn't
> > found a switch for gcc to turn these warnings off ... ;-)
>
> Why would casting make code unreadable? Casting makes it clear what the
> code is intended to do.
>
>
Putting a cast statement in front of every psuedo-forth word in the
following example would make it un-readable:
eg:
// 446 DIGIT? ( c base -- u t )Convert a character to its numeric
value.
_DOCOL,RTO,DOLIT,'0',SUB,
DOLIT,9,OVER,LT,
ZBRANCH,&cfa[465],
DOLIT,7,SUB,
DUP,DOLIT,10,LT,OR,
/*465*/ DUP,RFROM,ULT,SEMI,
I want the code to be readable FORTH not C. (even though it is wriiten
in C)
So what if it results in some harmless compiler warnings ..
Cheers,
Bernard
Thomas Pornin
> Sorry, I don't know anything about MinGW, but is sounds as though
> you are missing part of the tools.
It depends on how you define "missing". Termios is loosely associated
with Unix. It is not part of the C standard library per se. The C
standard library contains the most basic functions, such as printf().
Gcc is a raw C compiler, which provides a C implementation when installed
along with an appropriate library.
Cygwin is a port of gcc for Windows, with a somewhat Posix library, thus
providing access to some Unix APIs such as termios.
MinGW is another port of gcc for Windows. It comes with a much more
minimal library, but it also has hooks to the Win32 API. Thus, MinGW
does not have the Unix APIs, but it has the Win32 APIs (which is my it
is often called the "native" port of gcc to Unix). MinGW lacks termios.
"This is not a bug, this is a feature".
--Thomas Pornin
Bernard Mentink
not
a "linux" or UNIX system, (the header file provided as an example is
specifically labelled linux.h, not
MinGW.h"
All Bill has to provide in the header is character-in/out functions and a
Kbhit function, again
a 5min port.
Cheers,
Bernard
On Mon, 18 Oct 2004 07:06:39 +0000 (UTC), Thomas Pornin <por...@nerim.net>
wrote:
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Thomas Pornin
> Ok, then a specific header file needs to be "ported" to MinGW since
> it is not a "linux" or UNIX system
A C header file only declares functions, it does not define them. The
<termios.h> header is not present in MinGW because if it was present, it
would declare functions which do not exist either. Such functions could
be implemented (that's what Cygwin does) but this would mean emulating
a Unix terminal, which the underlying OS (Windows) does not provide at
all.
In short, the program uses features (terminals) that Windows does not
provide (Windows provides consoles, which are not the same). The program
is not fully portable.
The usual way to implement terminal-based portable programs is
to rely on a terminal handling library (e.g., "slang" -- see
ftp://space.mit.edu/pub/davis/slang/ ) which will provide a nice
abstraction (well, at least nicer than Unix terminals) and hide the
grunt work of mapping that abstraction on whatever facilities are
provided by the underlying operating system.
Such layering is of course not very Forthish, but it is very useful when
trying to programs which may run on may Windows and Unix systems.
--Thomas Pornin