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

Groups > comp.lang.forth > #19218 > unrolled thread

Offline compilation of Forth

Back to article view | Back to comp.lang.forth

Contents

  Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-01-28 11:54 +0000
    Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-28 17:19 +0000
      Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-28 22:08 +0100
      Re: Offline compilation of Forth "Peter Knaggs" <pjk@bcs.org.uk> - 2013-02-03 10:50 +0000
        Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-03 12:11 +0000
          Re: Offline compilation of Forth "A. K." <akk@nospam.org> - 2013-02-03 14:59 +0100
            Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-03 15:14 +0100
              Re: Offline compilation of Forth Hannu Vuolasaho <hannu.vuolasaho@nospam.tut.fi.invalid> - 2013-02-03 15:25 +0000
            Re: Offline compilation of Forth Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-05 08:13 -0800
        Re: Offline compilation of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 16:23 +0000
    Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-28 12:26 -1000
    Re: Offline compilation of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 08:55 +0000
      Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-29 17:49 +0100
        Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-01-30 00:42 -0800
          Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-30 11:58 +0000
          Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-01-30 23:16 -0800
            Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-31 13:29 +0000
              Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-03 12:49 +1100
                Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 20:37 -0800
        Re: Offline compilation of Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-03 21:15 +0200
          Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-04 02:04 +0100
        Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-04 13:22 +0000
          Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-04 20:07 +0100
            Re: Offline compilation of Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-04 23:07 +0200
              Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 18:33 +0100
                Re: Offline compilation of Forth mhx@iae.nl (Marcel Hendrix) - 2013-02-06 22:53 +0200
                  Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-07 00:30 +0100
      Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-01-30 00:36 -0800
    Re: Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-01-30 18:12 +0000
      Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-30 09:36 -1000
      Re: Offline compilation of Forth "A. K." <akk@nospam.org> - 2013-01-31 07:45 +0100
      Re: Offline compilation of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-31 03:37 -0600
        Re: Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-02-01 00:01 +0000
          Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 14:59 -1000
            Re: Offline compilation of Forth Lauri Alanko <la@iki.fi> - 2013-02-05 15:17 +0000
              Re: Offline compilation of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 10:46 -0600
                Re: Offline compilation of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 18:47 +0100
      Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-01-31 21:47 +1100
        Re: Offline compilation of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-31 06:12 -0600
          Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-31 13:32 +0000
          Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 08:27 -1000
            Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-01 10:23 +1100
              Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 13:53 -1000
                Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-01 03:17 +0000
                  Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 18:43 -1000
                  Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-01 08:45 -0800
                Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-01-31 23:05 -0800
                  Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-01-31 21:25 -1000
                  Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-01 08:55 -0800
                    Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-01 09:18 -1000
                      Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-02-01 13:04 -0800
                Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-03 11:20 +1100
                  Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-03 12:20 +0000
                    Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-03 07:22 -0800
                      Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-03 17:54 +0000
                        Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-03 10:17 -0800
                        Re: Offline compilation of Forth albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-03 19:33 +0000
                          Re: Offline compilation of Forth Paul Rubin <no.email@nospam.invalid> - 2013-02-03 11:53 -0800
                            Re: Offline compilation of Forth Coos Haak <chforth@hccnet.nl> - 2013-02-04 00:59 +0100
                          Re: Offline compilation of Forth Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2013-02-04 11:38 +0100
                        Re: Offline compilation of Forth Brad Eckert <hwfwguy@gmail.com> - 2013-02-06 09:13 -0800
                          Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:02 -0800
                        Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 20:55 -0800
                      Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-03 08:26 -1000
                    Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-05 13:04 +1100
                      Re: Offline compilation of Forth stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-05 10:33 +0000
                        Re: Offline compilation of Forth "Elizabeth D. Rather" <erather@forth.com> - 2013-02-05 08:56 -1000
                          Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-08 02:07 +1100
                            Re: Offline compilation of Forth Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-02-07 19:03 +0100
                              Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-09 22:45 +1100
                                Re: Offline compilation of Forth Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-02-09 18:56 +0100
                                  Re: Offline compilation of Forth Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2013-02-11 00:19 +0100
                                Re: Offline compilation of Forth Alex McDonald <blog@rivadpm.com> - 2013-02-09 11:59 -0800
                                  Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-13 13:13 +1100
                                    Re: Offline compilation of Forth Alex McDonald <blog@rivadpm.com> - 2013-02-12 19:19 -0800
                          Re: Offline compilation of Forth "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:01 -0800
        Re: Offline compilation of Forth Roberto Waltman <usenet@rwaltman.com> - 2013-02-03 16:26 -0500
          Re: Offline compilation of Forth "Ed" <invalid@nospam.com> - 2013-02-05 15:32 +1100
            Re: Offline compilation of Forth Mark Wills <forthfreak@gmail.com> - 2013-02-04 23:18 -0800

Page 4 of 4 — ← Prev page 1 2 3 [4]

#19510

On Sunday, February 3, 2013 10:54:32 AM UTC-7, Stephen Pelc wrote:
> These days, one should use a CPU on which
> one can fit a resident interpreter. Add there are such devices with
> power consumption similar to or better than low-end MSP430s.
> 

Just to elaborate on this, a resident interpreter gives you some nice flexibility:

1. A thin client debugger needs the application source code and a means to reload the kernel to make it match what gets compiled. Without a resident interpreter, you would have to distribute both the source code and the cross compiler in order to provide basic debugging capabilities.

2. The umbilical link and the text interpreter can share the same serial link, since nothing you type will be interpreted as an XTL command.

3. Reloading the kernel can be dangerous, since replacing it with crap could dead-brick your device.

[toc] | [prev] | [next] | [standalone]

#19750

On Wednesday, February 6, 2013 11:13:32 AM UTC-6, Brad Eckert wrote:
> On Sunday, February 3, 2013 10:54:32 AM UTC-7, Stephen Pelc wrote:
> 
> > These days, one should use a CPU on which
> 
> > one can fit a resident interpreter. Add there are such devices with
> 
> > power consumption similar to or better than low-end MSP430s.
> 
> > 
> 
> 
> 
> Just to elaborate on this, a resident interpreter gives you some nice flexibility:
> 
> 
> 
> 1. A thin client debugger needs the application source code and a means to reload the kernel to make it match what gets compiled. Without a resident interpreter, you would have to distribute both the source code and the cross compiler in order to provide basic debugging capabilities.
> 
> 
> 
> 2. The umbilical link and the text interpreter can share the same serial link, since nothing you type will be interpreted as an XTL command.
> 
> 
> 
> 3. Reloading the kernel can be dangerous, since replacing it with crap could dead-brick your device.

Agree with this experience.

[toc] | [prev] | [next] | [standalone]

#19748

On Sunday, February 3, 2013 11:54:32 AM UTC-6, Stephen Pelc wrote:
> On Sun, 03 Feb 2013 07:22:50 -0800, Paul Rubin
> 
> <no.email@nospam.invalid> wrote:
> 
> 
> 
> >stephenXXX@mpeforth.com (Stephen Pelc) writes:
> 
> >> I certainly do worry about memory usage in embedded systems, but
> 
> >> there I worry about RAM usage, not about code size.
> 
> >
> 
> >When I think of cross-compilation, one target that immediately comes
> 
> >to mind is the smaller of the two TI MSP430 Launchpad processors, with
> 
> >2k of program flash and 128 bytes of ram.  That certainly seems
> 
> >reasonable to cross-compile for, but awfully constrained for a resident
> 
> >interpreter.
> 
> 
> 
> There's a reason why the Forth vendors developed Umbilical Forths.
> 
> 
> 
> ANd your point is? I have never claimed that one should fit a resident
> 
> interpreter on such a CPU. These days, one should use a CPU on which
> 
> one can fit a resident interpreter. Add there are such devices with
> 
> power consumption similar to or better than low-end MSP430s.
> 
> 
> 
> >Even the bigger cpu (16k flash, 512 bytes ram) leads
> 
> >to a rather stripped down interpreter (4e4th tries to fit in 8k of
> 
> >the flash to leave the other 8k for user code).
> 
> 
> 
> So use a bigger CPU?
> 
> 
> 
> One problem with the discussion about resident Forths on Launchpads
> 
> is that it's the usual fatuous assumption that cheaper is better.
> 
> The underfunded education world has a reason to need cheap, but 
> 
> a far better long-term solution is to fund education properly.
> 
Amen. Any Nations doing this may, in the not to distance speed-ed up by technology future, benefit profusely. On the other hand funding in all Nations/Governments are easily lobbied to purchase the bloated solution that comes from monopolist and kickback persuasions.

I'd like to get a simple standard FORTH on every eval board I buy. If I was a mfg I'd be talking to you.

[toc] | [prev] | [next] | [standalone]

#19401

On 2/3/13 5:22 AM, Paul Rubin wrote:
> stephenXXX@mpeforth.com (Stephen Pelc) writes:
>> I certainly do worry about memory usage in embedded systems, but
>> there I worry about RAM usage, not about code size.
>
> When I think of cross-compilation, one target that immediately comes
> to mind is the smaller of the two TI MSP430 Launchpad processors, with
> 2k of program flash and 128 bytes of ram.  That certainly seems
> reasonable to cross-compile for, but awfully constrained for a resident
> interpreter.  Even the bigger cpu (16k flash, 512 bytes ram) leads
> to a rather stripped down interpreter (4e4th tries to fit in 8k of
> the flash to leave the other 8k for user code).
>

Sure. SwiftX can support an application in this target, but including a 
resident interpreter would obviously be inappropriate. Stephen was 
referring to the more typical configuration with very large code space 
(aimed at a market using C compilers), and I agree with him. The low-end 
devices are intended for targets in which a resident interpreter would 
not offer any benefit, in any case.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#19440

Stephen Pelc wrote:
> On Sun, 3 Feb 2013 11:20:36 +1100, "Ed" <invalid@nospam.com> wrote:
>
> >I would say the option to generate compilerless turnkeys should be
> >available all systems - particularly the large Forth systems of today.
> >If the *only* reason they generate 400 Kb "Hello World" executables
> >(800 Kb in the case of SwiftForth) is because they're using 1970's
> >implementation methods, then perhaps it's time for a re-think.
> >Strategies for keeping the compiler separate from the code it
> >generates have been around since at least the 1980's.
>
> But why? If ultimate performance is your goal, then there is
> merit in keeping applications smaller than the size of the cache.
> Otherwise, on computers with 1Gb or more of RAM, and the largest
> desktop Forth app I know of being 22Mb plus a few DLLs, we can
> say that Forth apps occupy less than 2.5% of the available RAM.
> Why on earth should I worry about the size of the Forth kernel?
> ...

Because waste is unnecessary and never cost-free?

I download many Win apps from the net in order to find one that
works and/or is suitable.  I don't have infinite time or bandwidth.
It would be more than annoying if each of those apps included
an extra 700 Kb of code due to the unnecessary presence of
a compiler.  The same would apply if I were a Forth customer
wanting to distribute small or medium sized apps on the internet.

One of the standard tests applied to compilers was the size
of the executables it produced.  Chuck claimed Forth was small.
In that case it should be at the top of the list.  How hard can
it be.

[toc] | [prev] | [next] | [standalone]

#19448

On Tue, 5 Feb 2013 13:04:16 +1100, "Ed" <invalid@nospam.com> wrote:

>> Otherwise, on computers with 1Gb or more of RAM, and the largest
>> desktop Forth app I know of being 22Mb plus a few DLLs, we can
>> say that Forth apps occupy less than 2.5% of the available RAM.
>> Why on earth should I worry about the size of the Forth kernel?
>> ...
>
>Because waste is unnecessary and never cost-free?

That's true, but how do you measure the cost? Implementing a
minimal kernel is itself a cost. For a desktop Forth, clients
want new features far more than they want a minimal kernel.

In terms of measuring time and money, a minimal desktop kernel
is not commercially viable. In terms of paying obeisance to
our founder, it may have merit. And would be balm to my soul
to indicate that I'm still capable of working that small.

But I have embedded systems for that purpose now.

The desktop world has changed and in a measurable proportion
of those applications we use the text interpreter at run-time.

I could measure bandwidth costs, but thet are plummeting yearly.
In a few years you won't even thing about the costs of downloading
a compressed 25Mb executable. For several years now, we have shipped
the majority of our systems electronically. Guess how many complaints
we have had about the download size? That's right, none, zero.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
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.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#19480

On 2/5/13 12:33 AM, Stephen Pelc wrote:
> On Tue, 5 Feb 2013 13:04:16 +1100, "Ed" <invalid@nospam.com> wrote:
>
>>> Otherwise, on computers with 1Gb or more of RAM, and the largest
>>> desktop Forth app I know of being 22Mb plus a few DLLs, we can
>>> say that Forth apps occupy less than 2.5% of the available RAM.
>>> Why on earth should I worry about the size of the Forth kernel?
>>> ...
>>
>> Because waste is unnecessary and never cost-free?

True. Even on modern computers with vast memories, when you run a lot of 
programs such as MS Word, Photoshop, and other very complex and enormous 
programs a major performance drag is memory management.

But when you set about reducing waste, there is also a cost. One has to 
make value judgements about the cost of certain waste vs. the cost of 
preventing it. Which leads us to...

> That's true, but how do you measure the cost? Implementing a
> minimal kernel is itself a cost. For a desktop Forth, clients
> want new features far more than they want a minimal kernel.

That's just as true of Forth as of the mammoth programs I mentioned above.

> In terms of measuring time and money, a minimal desktop kernel
> is not commercially viable. In terms of paying obeisance to
> our founder, it may have merit. And would be balm to my soul
> to indicate that I'm still capable of working that small.
>
> But I have embedded systems for that purpose now.

Exactly.

> The desktop world has changed and in a measurable proportion
> of those applications we use the text interpreter at run-time.
>
> I could measure bandwidth costs, but thet are plummeting yearly.
> In a few years you won't even thing about the costs of downloading
> a compressed 25Mb executable. For several years now, we have shipped
> the majority of our systems electronically. Guess how many complaints
> we have had about the download size? That's right, none, zero.

Well, Ed just complained about SwiftForth, so I can't say 'zero', but 
given that not only SwiftForth but all the SwiftForth applications I'm 
familiar with are a tiny fraction of the size of most popular 
applications, we have, like Stephen, made the judgement call that the 
cost of making a few-Kb kernel for a multi-Gb target is not justified. 
And most of our users (AFAIK all but Ed) agree.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#19523

Elizabeth D. Rather wrote:
> ...
> Well, Ed just complained about SwiftForth, so I can't say 'zero', but
> given that not only SwiftForth but all the SwiftForth applications I'm
> familiar with are a tiny fraction of the size of most popular
> applications, we have, like Stephen, made the judgement call that the
> cost of making a few-Kb kernel for a multi-Gb target is not justified.
> And most of our users (AFAIK all but Ed) agree.

I don't call myself a user so feel free to count me out.  But check out
the SFtalk mail list and you'll find at least one user asking about it
("Swiftforth Metacompiler?" and "SwiftForth 3.0.2").  In fact you replied
to them.  Who can say how many prospective clients have looked at
Forth but instead chosen C because their compilers did what was
needed.  Not everyone writes 10+ Mb programs.  There are C compilers
that will happily turn out a 70 Kb Win console app (freeware ones at that).
I can understand it may not be commercially viable for Forth vendors
compete with them.  It doesn't however mean Forth hobbyists need
suffer the same limitations as vendor implementations.

[toc] | [prev] | [next] | [standalone]

#19525

In article <kf0fve$iuc$1@speranza.aioe.org>, "Ed" <invalid@nospam.com> 
wrote:

> Elizabeth D. Rather wrote:
> > ...
> > Well, Ed just complained about SwiftForth, so I can't say 'zero', but
> > given that not only SwiftForth but all the SwiftForth applications I'm
> > familiar with are a tiny fraction of the size of most popular
> > applications, we have, like Stephen, made the judgement call that the
> > cost of making a few-Kb kernel for a multi-Gb target is not justified.
> > And most of our users (AFAIK all but Ed) agree.
> 
> I don't call myself a user so feel free to count me out.  But check out
> the SFtalk mail list and you'll find at least one user asking about it
> ("Swiftforth Metacompiler?" and "SwiftForth 3.0.2").  In fact you replied
> to them.  Who can say how many prospective clients have looked at
> Forth but instead chosen C because their compilers did what was
> needed.  Not everyone writes 10+ Mb programs.  There are C compilers
> that will happily turn out a 70 Kb Win console app (freeware ones at that).
> I can understand it may not be commercially viable for Forth vendors
> compete with them.  It doesn't however mean Forth hobbyists need
> suffer the same limitations as vendor implementations.

Hi Ed,

So what's considered a few-Kb kernel?
On OSX the out of the box extended SF will produce a standalone 
HelloWorld in 242 Kb. Using UNCALLED one can strip, manually, the 
included files to a certain minimum. At what cost? My time, pffffffffff.
Much simpler is to recompile the SFK kernel with the supplied 
crosscompiler and replace QUIT with HelloWorld. Minimal efford (and thus 
minimal costs): 95 Kb.
For this special case, one can go further and comment out 1/3 of the
kernel files. The resulting app is 41 Kb. I could continue trimming by 
trial and error. But no time left. Anyway the vendor provides me with 
the tools to achieve this. It only needs to be done at the users 
expense, he/she has to put some effort in to it. I don't think that's 
bad.

I know 2 desktop GUI Forth systems from the 1980ies capable of doing 
what you suggested. jForth on the Amiga created standalone apps via 
target compiling. Mach2 for Mac and Atari did it by _not_ saving the 
dictionary header space and unused code segments (compiler, debugger, 
editors, asembler/disassembler, etc.) in the turnkey.
Selling point in the advertisements for both Forth systems, was creating 
standalone applications like any other development system on those 
platforms wrt size, execution speed and GUI capabilities (both systems 
were 32bit 68000 jsr+optimization threaded).

Truth is, I did not see many applications made that way. Most of us used 
these systems without turnkeying our work. I still don't use turnkey 
apart as a way to extend the system (in some systems called SNAPSHOT 
SAVE-SYSTEM WORKSPACE etc.). But in the (unlikely) event I have to, I'll 
certainly will take measures to put some sanity in the system :-)

Regards,
Roelf

[toc] | [prev] | [next] | [standalone]

#19576

Roelf Toxopeus wrote:
>
> Hi Ed,
>
> So what's considered a few-Kb kernel?
>
> On OSX the out of the box extended SF will produce a standalone
> HelloWorld in 242 Kb. Using UNCALLED one can strip, manually, the
> included files to a certain minimum. At what cost? My time, pffffffffff.
> Much simpler is to recompile the SFK kernel with the supplied
> crosscompiler and replace QUIT with HelloWorld. Minimal efford (and thus
> minimal costs): 95 Kb.
> For this special case, one can go further and comment out 1/3 of the
> kernel files. The resulting app is 41 Kb. I could continue trimming by
> trial and error. But no time left. Anyway the vendor provides me with
> the tools to achieve this. It only needs to be done at the users
> expense, he/she has to put some effort in to it. I don't think that's
> bad.

But this requires specialist knowledge and not a little effort.  As processes
go it is far from "user-friendly".

Compiler and related stuff represent the bulk of Forth systems today.
Don't include the compiler in the turnkey and there is an automatic and
substantial saving in size.  In my case I select TURNKEY or TURNKEY-
SYSTEM and the job is done.

> I know 2 desktop GUI Forth systems from the 1980ies capable of doing
> what you suggested. jForth on the Amiga created standalone apps via
> target compiling. Mach2 for Mac and Atari did it by _not_ saving the
> dictionary header space and unused code segments (compiler, debugger,
> editors, asembler/disassembler, etc.) in the turnkey.
> Selling point in the advertisements for both Forth systems, was creating
> standalone applications like any other development system on those
> platforms wrt size, execution speed and GUI capabilities (both systems
> were 32bit 68000 jsr+optimization threaded).
>
> Truth is, I did not see many applications made that way. Most of us used
> these systems without turnkeying our work. I still don't use turnkey
> apart as a way to extend the system (in some systems called SNAPSHOT
> SAVE-SYSTEM WORKSPACE etc.). But in the (unlikely) event I have to, I'll
> certainly will take measures to put some sanity in the system :-)

Virtually all my apps end up as compilerless turnkeys.  I can only remember
one case where I needed to save the compiler - a standalone screen editor.

Even for folks who aren't likely to benefit from a system such as DX-Forth,
Win32Forth, JForth etc. it's nice to have the choice.  Retrofitting existing
forths may be difficult but new systems should certainly consider it.

[toc] | [prev] | [next] | [standalone]

#19585

In article <kf5ct8$dkv$1@speranza.aioe.org>, "Ed" <invalid@nospam.com> 
wrote:

> Roelf Toxopeus wrote:
> >
> > Hi Ed,
> >
> > So what's considered a few-Kb kernel?
> >
> > On OSX the out of the box extended SF will produce a standalone
> > HelloWorld in 242 Kb. Using UNCALLED one can strip, manually, the
> > included files to a certain minimum. At what cost? My time, pffffffffff.
> > Much simpler is to recompile the SFK kernel with the supplied
> > crosscompiler and replace QUIT with HelloWorld. Minimal efford (and thus
> > minimal costs): 95 Kb.
> > For this special case, one can go further and comment out 1/3 of the
> > kernel files. The resulting app is 41 Kb. I could continue trimming by
> > trial and error. But no time left. Anyway the vendor provides me with
> > the tools to achieve this. It only needs to be done at the users
> > expense, he/she has to put some effort in to it. I don't think that's
> > bad.
> 
> But this requires specialist knowledge and not a little effort.  As processes
> go it is far from "user-friendly".

Compared to TURNKEY as you and I know it, it's not. But absolutely 
doable if you want to (most is just in the manual, but some experience 
probably helps).

> 
> Compiler and related stuff represent the bulk of Forth systems today.

In this case the compiler doesn't take up a lot of space at all, it's 
mostly the unused dictionary code and all the headers.

[...]

> > Truth is, I did not see many applications made that way. Most of us used
> > these systems without turnkeying our work. I still don't use turnkey
> > apart as a way to extend the system (in some systems called SNAPSHOT
> > SAVE-SYSTEM WORKSPACE etc.). But in the (unlikely) event I have to, I'll
> > certainly will take measures to put some sanity in the system :-)
> 
> Virtually all my apps end up as compilerless turnkeys.  I can only remember
> one case where I needed to save the compiler - a standalone screen editor.
> 
> Even for folks who aren't likely to benefit from a system such as DX-Forth,
> Win32Forth, JForth etc. it's nice to have the choice.  Retrofitting existing
> forths may be difficult but new systems should certainly consider it.

Fully agreed (and the crosscompiler got me thinking :0).
Still there's the question of costs...

thank you and regards,
Roelf

[toc] | [prev] | [next] | [standalone]

#19613

In article <rt4all-679368.18565509022013@[10.12.75.213]>,
 Roelf Toxopeus <rt4all@notthis.hetnet.nl> wrote:

> In article <kf5ct8$dkv$1@speranza.aioe.org>, "Ed" <invalid@nospam.com> 
> wrote:
> 
> > Roelf Toxopeus wrote:
> > >
> > > Hi Ed,
> > >
> > > So what's considered a few-Kb kernel?
> > >
> > > On OSX the out of the box extended SF will produce a standalone
> > > HelloWorld in 242 Kb. Using UNCALLED one can strip, manually, the
> > > included files to a certain minimum. At what cost? My time, pffffffffff.
> > > Much simpler is to recompile the SFK kernel with the supplied
> > > crosscompiler and replace QUIT with HelloWorld. Minimal efford (and thus
> > > minimal costs): 95 Kb.
> > > For this special case, one can go further and comment out 1/3 of the
> > > kernel files. The resulting app is 41 Kb. I could continue trimming by
> > > trial and error. But no time left. Anyway the vendor provides me with
> > > the tools to achieve this. It only needs to be done at the users
> > > expense, he/she has to put some effort in to it. I don't think that's
> > > bad.
> > 
> > But this requires specialist knowledge and not a little effort.  As 
> > processes
> > go it is far from "user-friendly".
> 
> Compared to TURNKEY as you and I know it, it's not. But absolutely 
> doable if you want to (most is just in the manual, but some experience 
> probably helps).

Lo and behold! Found similar answers how to do it in the SF user archives
1999 and 2002. Should have checked there first of course, what a mug I 
am!

[...]

> > > I still don't use turnkey
> > > apart as a way to extend the system (in some systems called SNAPSHOT
> > > SAVE-SYSTEM WORKSPACE etc.). But in the (unlikely) event I have to, I'll
> > > certainly will take measures to put some sanity in the system :-)

Actually I lied, how could I forget. Allthough I'm not using turnkey for 
my own work, I used to make sure the code I published survives a 
turnkey/snapshot in case someone uses this function (on different OSX 
versions). And it's not only my own 'features' I discovered this way...

Quite an interesting way of usage.

-r

[toc] | [prev] | [next] | [standalone]

#19586

On Feb 9, 11:45 am, "Ed" <inva...@nospam.com> wrote:
> Roelf Toxopeus wrote:
>
> > Hi Ed,
>
> > So what's considered a few-Kb kernel?
>
> > On OSX the out of the box extended SF will produce a standalone
> > HelloWorld in 242 Kb. Using UNCALLED one can strip, manually, the
> > included files to a certain minimum. At what cost? My time, pffffffffff.
> > Much simpler is to recompile the SFK kernel with the supplied
> > crosscompiler and replace QUIT with HelloWorld. Minimal efford (and thus
> > minimal costs): 95 Kb.
> > For this special case, one can go further and comment out 1/3 of the
> > kernel files. The resulting app is 41 Kb. I could continue trimming by
> > trial and error. But no time left. Anyway the vendor provides me with
> > the tools to achieve this. It only needs to be done at the users
> > expense, he/she has to put some effort in to it. I don't think that's
> > bad.
>
> But this requires specialist knowledge and not a little effort.  As processes
> go it is far from "user-friendly".
>
> Compiler and related stuff represent the bulk of Forth systems today.
> Don't include the compiler in the turnkey and there is an automatic and
> substantial saving in size.  In my case I select TURNKEY or TURNKEY-
> SYSTEM and the job is done.
>
> > I know 2 desktop GUI Forth systems from the 1980ies capable of doing
> > what you suggested. jForth on the Amiga created standalone apps via
> > target compiling. Mach2 for Mac and Atari did it by _not_ saving the
> > dictionary header space and unused code segments (compiler, debugger,
> > editors, asembler/disassembler, etc.) in the turnkey.
> > Selling point in the advertisements for both Forth systems, was creating
> > standalone applications like any other development system on those
> > platforms wrt size, execution speed and GUI capabilities (both systems
> > were 32bit 68000 jsr+optimization threaded).
>
> > Truth is, I did not see many applications made that way. Most of us used
> > these systems without turnkeying our work. I still don't use turnkey
> > apart as a way to extend the system (in some systems called SNAPSHOT
> > SAVE-SYSTEM WORKSPACE etc.). But in the (unlikely) event I have to, I'll
> > certainly will take measures to put some sanity in the system :-)
>
> Virtually all my apps end up as compilerless turnkeys.  I can only remember
> one case where I needed to save the compiler - a standalone screen editor.
>
> Even for folks who aren't likely to benefit from a system such as DX-Forth,
> Win32Forth, JForth etc. it's nice to have the choice.  Retrofitting existing
> forths may be difficult but new systems should certainly consider it.

The documentation will outweigh the size of a 60KB or 600KB executable
by am order of magnitude. Would you leave it out to save transmission
time and space?

I wouldn't consider the programming, debugging and maintenance effort
to be an adequate trade off for the extremely small increase in
network cost or storage savings over the lifetime of such a program.

[toc] | [prev] | [next] | [standalone]

#19691

Alex McDonald wrote:
> On Feb 9, 11:45 am, "Ed" <inva...@nospam.com> wrote:
> ...
> > Even for folks who aren't likely to benefit from a system such as DX-Forth,
> > Win32Forth, JForth etc. it's nice to have the choice. Retrofitting existing
> > forths may be difficult but new systems should certainly consider it.
>
> The documentation will outweigh the size of a 60KB or 600KB executable
> by am order of magnitude. Would you leave it out to save transmission
> time and space?

In answer to your question I include only that which is necessary.
If the compiler is unnecessary, I don't include it.

I've written far more in posts on c.l.f. than I'll ever write in docs.
Perhaps you too :)

[toc] | [prev] | [next] | [standalone]

#19693

On Feb 12, 6:13 pm, "Ed" <inva...@nospam.com> wrote:
> Alex McDonald wrote:
> > On Feb 9, 11:45 am, "Ed" <inva...@nospam.com> wrote:
> > ...
> > > Even for folks who aren't likely to benefit from a system such as DX-Forth,
> > > Win32Forth, JForth etc. it's nice to have the choice. Retrofitting existing
> > > forths may be difficult but new systems should certainly consider it.
>
> > The documentation will outweigh the size of a 60KB or 600KB executable
> > by am order of magnitude. Would you leave it out to save transmission
> > time and space?
>
> In answer to your question I include only that which is necessary.
> If the compiler is unnecessary, I don't include it.

That is not the question I asked. You are answering a question about
need rather than size.

Since the effort of supporting such a turnkey system is a major source
of programmer effort, adds lines of code that will have bugs, and
requires maintenance/support, why would you make the investment? If
simplicity is your goal, then I would suggest that it is best
practiced in source code, not in the binary.

It may be desirable for commercial products or applications to have
such a feature and retain the compiler as a chargeable item. Since we
stopped using floppies to distribute software, the size of the
executable no longer plays a part in the cost/revenue decision.

>
> I've written far more in posts on c.l.f. than I'll ever write in docs.
> Perhaps you too :)

Not quite.

[toc] | [prev] | [next] | [standalone]

#19749

On Tuesday, February 5, 2013 12:56:02 PM UTC-6, Elizabeth D. Rather wrote:
> On 2/5/13 12:33 AM, Stephen Pelc wrote:
> 
> > On Tue, 5 Feb 2013 13:04:16 +1100, "Ed" <invalid@nospam.com> wrote:
> 
> >
> 
> >>> Otherwise, on computers with 1Gb or more of RAM, and the largest
> 
> >>> desktop Forth app I know of being 22Mb plus a few DLLs, we can
> 
> >>> say that Forth apps occupy less than 2.5% of the available RAM.
> 
> >>> Why on earth should I worry about the size of the Forth kernel?
> 
> >>> ...
> 
> >>
> 
> >> Because waste is unnecessary and never cost-free?
> 
> 
> 
> True. Even on modern computers with vast memories, when you run a lot of 
> 
> programs such as MS Word, Photoshop, and other very complex and enormous 
> 
> programs a major performance drag is memory management.
> 
> 
> 
> But when you set about reducing waste, there is also a cost. One has to 
> 
> make value judgements about the cost of certain waste vs. the cost of 
> 
> preventing it. Which leads us to...
> 
> 
> 
> > That's true, but how do you measure the cost? Implementing a
> 
> > minimal kernel is itself a cost. For a desktop Forth, clients
> 
> > want new features far more than they want a minimal kernel.
> 
> 
> 
> That's just as true of Forth as of the mammoth programs I mentioned above.
> 
> 
> 
> > In terms of measuring time and money, a minimal desktop kernel
> 
> > is not commercially viable. In terms of paying obeisance to
> 
> > our founder, it may have merit. And would be balm to my soul
> 
> > to indicate that I'm still capable of working that small.
> 
> >
> 
> > But I have embedded systems for that purpose now.
> 
> 
> 
> Exactly.
> 
> 
> 
> > The desktop world has changed and in a measurable proportion
> 
> > of those applications we use the text interpreter at run-time.
> 
> >
> 
> > I could measure bandwidth costs, but thet are plummeting yearly.
> 
> > In a few years you won't even thing about the costs of downloading
> 
> > a compressed 25Mb executable. For several years now, we have shipped
> 
> > the majority of our systems electronically. Guess how many complaints
> 
> > we have had about the download size? That's right, none, zero.
> 
> 
> 
> Well, Ed just complained about SwiftForth, so I can't say 'zero', but 
> 
> given that not only SwiftForth but all the SwiftForth applications I'm 
> 
> familiar with are a tiny fraction of the size of most popular 
> 
> applications, we have, like Stephen, made the judgement call that the 
> 
> cost of making a few-Kb kernel for a multi-Gb target is not justified. 
> 
> And most of our users (AFAIK all but Ed) agree.

Sympathetic VCITW.

[toc] | [prev] | [next] | [standalone]

#19408

"Ed"  wrote:
>....  There's a pdf
>manual for RSC-Forth on the internet which explains how it works.

Found  a copy here:
www.smallestplcoftheworld.org/RSC-FORTH_User's_Manual.pdf
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#19442

Roberto Waltman wrote:
> "Ed"  wrote:
> >....  There's a pdf
> >manual for RSC-Forth on the internet which explains how it works.
>
> Found  a copy here:
> www.smallestplcoftheworld.org/RSC-FORTH_User's_Manual.pdf
> --
> Roberto Waltman
>
> [ Please reply to the group,
>   return address is invalid ]

I first came across the manual in an engineering library in the
late 80's.  It had one of the best quick intros to Forth I've seen.
Nice to see someone scanned it in.

[toc] | [prev] | [next] | [standalone]

#19444

On Feb 5, 4:32 am, "Ed" <inva...@nospam.com> wrote:
> Roberto Waltman wrote:
> > "Ed"  wrote:
> > >....  There's a pdf
> > >manual for RSC-Forth on the internet which explains how it works.
>
> > Found  a copy here:
> >www.smallestplcoftheworld.org/RSC-FORTH_User's_Manual.pdf
> > --
> > Roberto Waltman
>
> > [ Please reply to the group,
> >   return address is invalid ]
>
> I first came across the manual in an engineering library in the
> late 80's.  It had one of the best quick intros to Forth I've seen.
> Nice to see someone scanned it in.

Corrected link to the PDF:

http://www.smallestplcoftheworld.org/RSC-FORTH_User's_Manual.pdf

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.forth

csiph-web