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

Was just wondering when people started using C to write forth languages and not assembly?

Started by	Darin Murphy <murphy.darin@gmail.com>
First post	2016-05-18 11:31 -0700
Last post	2016-05-20 22:27 -0400
Articles	20 on this page of 75 — 20 participants

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

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

#47312

From	Ron Aaron <rambamist@gmail.com>
Date	2016-05-19 19:21 +0300
Message-ID	<nhkp0a$6cn$1@dont-email.me>
In reply to	#47311

On 19/05/2016 18:07, Anton Ertl wrote:

> 
> Yes, with the current attitude of C compiler maintainers, assembly
> language is much more reliable and solid than C.  Also, the number of
> relevant architectures is shrinking, so the additional portability
> effort for assembly language is getting smaller.

Perhaps, but supporting 32 and 64-bit variants of ARM and Intel is
already four different ports.  Add in the variations of ABIs between
systems and you have considerably more.  It quickly becomes a real pain
to maintain.

> Except that the GCC maintainers don't have that expert knowledge 

Unfortunately, that's true.

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

#47339

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-20 12:44 +0000
Message-ID	<2016May20.144448@mips.complang.tuwien.ac.at>
In reply to	#47312

Ron Aaron <rambamist@gmail.com> writes:
>On 19/05/2016 18:07, Anton Ertl wrote:
>
>> 
>> Yes, with the current attitude of C compiler maintainers, assembly
>> language is much more reliable and solid than C.  Also, the number of
>> relevant architectures is shrinking, so the additional portability
>> effort for assembly language is getting smaller.
>
>Perhaps, but supporting 32 and 64-bit variants of ARM and Intel is
>already four different ports.

Yes, although 32-bit Intel is superfluous these days.  Might also
happen to 32-bit ARM before we are done with the switch to assembly.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#47341

From	Ron Aaron <rambamist@gmail.com>
Date	2016-05-20 16:14 +0300
Message-ID	<nhn2db$nv0$1@dont-email.me>
In reply to	#47339

On 20/05/2016 15:44, Anton Ertl wrote:

> Yes, although 32-bit Intel is superfluous these days.  Might also
> happen to 32-bit ARM before we are done with the switch to assembly.

Don't be so sure.

I've got people who use 8th on 32-bit Linux systems (and 32-bit
Windows), and can't or won't switch.  Not to mention that most Android
devices are 32-bit.

The "e8th" port for embedded is also 32-bit. Worse, it's "dwarf" and not
"arm"... yet another variant to handle.

Yes, 64-bit will be "the future", but the "the past" will be with us for
a long, long time.

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

#47342

From	Lars Brinkhoff <lars.spam@nocrew.org>
Date	2016-05-20 15:28 +0200
Message-ID	<86zirkkge2.fsf@molnjunk.nocrew.org>
In reply to	#47341

Ron Aaron <rambamist@gmail.com> writes:
> On 20/05/2016 15:44, Anton Ertl wrote:
>> Yes, although 32-bit Intel is superfluous these days.  Might also
>> happen to 32-bit ARM before we are done with the switch to assembly.
> Don't be so sure.

There are also popular Thumb-only devices, so full ARM support may be
three targets.

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

#47344

From	stephen@mpeforth.com (Stephen Pelc)
Date	2016-05-20 13:50 +0000
Message-ID	<573f14dc.154153604@news.eternal-september.org>
In reply to	#47342

On Fri, 20 May 2016 15:28:37 +0200, Lars Brinkhoff
<lars.spam@nocrew.org> wrote:

>Ron Aaron <rambamist@gmail.com> writes:
>> On 20/05/2016 15:44, Anton Ertl wrote:
>>> Yes, although 32-bit Intel is superfluous these days.  Might also
>>> happen to 32-bit ARM before we are done with the switch to assembly.
>> Don't be so sure.
>
>There are also popular Thumb-only devices, so full ARM support may be
>three targets.

It's a lot worse than that ...
  ARM32 original ARM instruction set(s)
  ignore original Thumb-1
  Cotex-Ax (many phones)
  Cortex-M0 (ARMv6M, low end embedded)
  Cortex-M3+ (ARMv7M, higher end embedded)
  SIMD extensions
  VFP extensions
  ARMv8 64 bit
    there will be A and M profiles ...

ARM's view of instruction sets is that they will change the
instruction set as required by the silicon and the application.
Keeping up with all the new stuff is almost a full time job.

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]

#47345

From	Raimond Dragomir <raimond.dragomir@gmail.com>
Date	2016-05-20 07:31 -0700
Message-ID	<e6a61997-bc28-4a75-8fdb-ec14d44c646c@googlegroups.com>
In reply to	#47344

For mid-end embedded systems C is the only way. Don't tell me you will
implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in 
assembly... And also don't tell me that you are done with 64 primitives
and all others are calls to os services... What os services? And even
when there are os services, how they were compiled? in ASM? I doubt...
This also applies to os based systems: you implement a forth in asm but
all the hard stuff is implemented in C...

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

#47360

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-05-20 08:39 -1000
Message-ID	<dYWdndYvP_9PxKLKnZ2dnUU7-dHNnZ2d@supernews.com>
In reply to	#47345

On 5/20/16 4:31 AM, Raimond Dragomir wrote:
> For mid-end embedded systems C is the only way. Don't tell me you will
> implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in
> assembly... And also don't tell me that you are done with 64 primitives
> and all others are calls to os services... What os services? And even
> when there are os services, how they were compiled? in ASM? I doubt...
> This also applies to os based systems: you implement a forth in asm but
> all the hard stuff is implemented in C...

Hogwash. In the first place, nobody said they were "done with 64 
primitives." Neither Chuck nor anyone else stops there, that's a 
minimalist basis for getting started. If you want OS services (on an 
embedded platform or anywhere else) you can use a hosted Forth. That 
hosted Forth might be written in C, but doesn't need to be. Assembler 
primitives supporting high-level Forth work fine in such an environment.

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]

#47411

From	hughaguilar96@gmail.com
Date	2016-05-21 18:04 -0700
Message-ID	<a3197ca4-62a2-466c-86ba-9ca1a45d5556@googlegroups.com>
In reply to	#47360

On Friday, May 20, 2016 at 11:39:15 AM UTC-7, Elizabeth D. Rather wrote:
> On 5/20/16 4:31 AM, Raimond Dragomir wrote:
> > For mid-end embedded systems C is the only way. Don't tell me you will
> > implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in
> > assembly... And also don't tell me that you are done with 64 primitives
> > and all others are calls to os services... What os services? And even
> > when there are os services, how they were compiled? in ASM? I doubt...
> > This also applies to os based systems: you implement a forth in asm but
> > all the hard stuff is implemented in C...
> 
> Hogwash. In the first place, nobody said they were "done with 64 
> primitives." Neither Chuck nor anyone else stops there, that's a 
> minimalist basis for getting started. If you want OS services (on an 
> embedded platform or anywhere else) you can use a hosted Forth. That 
> hosted Forth might be written in C, but doesn't need to be. Assembler 
> primitives supporting high-level Forth work fine in such an environment.
> 
> Cheers,
> Elizabeth

Raimond is right. Theoretically, things like file systems, tcp/ip stacks, USB stacks, wireless stacks can be implemented in Forth, but for the most part you would use what is already available and is written in C.

I'm not volunteering to write a tcp/ip stack in Forth or any other language --- that is a lot of work! --- who is going to pay me to do that?

Elizabeth Rather is fantasizing --- confusing what could be done with what has been done --- lots of things could be done with Forth (Gavino will tell us all about what could be done with Forth), but that is not the same as actually doing it, which takes time and effort --- what could be done is not going to be done without some expectation of getting paid.

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

#47444 — Re: Was just wondering when people started using C to write forthlanguages and not assembly?

From	"WJ" <w_a_x_man@yahoo.com>
Date	2016-05-23 14:04 +0000
Subject	Re: Was just wondering when people started using C to write forthlanguages and not assembly?
Message-ID	<nhv2ke$8tr$1@dont-email.me>
In reply to	#47411

hughaguilar96@gmail.com wrote:

> On Friday, May 20, 2016 at 11:39:15 AM UTC-7, Elizabeth D. Rather wrote:
> > On 5/20/16 4:31 AM, Raimond Dragomir wrote:
> > > For mid-end embedded systems C is the only way. Don't tell me you will
> > > implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in
> > > assembly... And also don't tell me that you are done with 64 primitives
> > > and all others are calls to os services... What os services? And even
> > > when there are os services, how they were compiled? in ASM? I doubt...
> > > This also applies to os based systems: you implement a forth in asm but
> > > all the hard stuff is implemented in C...
> > 
> > Hogwash. In the first place, nobody said they were "done with 64 
> > primitives." Neither Chuck nor anyone else stops there, that's a 
> > minimalist basis for getting started. If you want OS services (on an 
> > embedded platform or anywhere else) you can use a hosted Forth. That 
> > hosted Forth might be written in C, but doesn't need to be. Assembler 
> > primitives supporting high-level Forth work fine in such an environment.
> > 
> > Cheers,
> > Elizabeth
> 
> Raimond is right. Theoretically, things like file systems,
> tcp/ip stacks, USB stacks, wireless stacks can be implemented
> in Forth, but for the most part you would use what is already
> available and is written in C.
> 
> I'm not volunteering to write a tcp/ip stack in Forth or any
> other language --- that is a lot of work! --- who is going to
> pay me to do that?
> 
> Elizabeth Rather is fantasizing --- confusing what could be
> done with what has been done --- lots of things could be done
> with Forth (Gavino will tell us all about what could be done
> with Forth), but that is not the same as actually doing it,
> which takes time and effort --- what could be done is not
> going to be done without some expectation of getting paid.

I think that this is further proof that Mrs. Rather is
a salesman, not a programmer.

-- 
"A Jew always has a much higher soul than a gentile, even if he is a
homosexual," he [Israel's Deputy Defense Minister Eli Ben-Dahan] said.
theoccidentalobserver.net/2015/10/israeli-minister-latest-in-long-line-of-jews-asserting-the-inferiority-of-non-jews

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

#47367

From	stephen@mpeforth.com (Stephen Pelc)
Date	2016-05-20 20:48 +0000
Message-ID	<573f77c8.179477746@news.eternal-september.org>
In reply to	#47345

On Fri, 20 May 2016 07:31:02 -0700 (PDT), Raimond Dragomir
<raimond.dragomir@gmail.com> wrote:

>For mid-end embedded systems C is the only way. Don't tell me you will
>implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in 
>assembly... 

No, but we have implemented them in Forth, and we do have Forth
compilers for many CPUs. They are good enough that I haven't written
an interrupt routine in assember for about 15 years - except to
prove that I can still do it.

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]

#47430

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-05-22 20:38 -0700
Message-ID	<874m9pigtp.fsf@jester.gateway.pace.com>
In reply to	#47345

Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> For mid-end embedded systems C is the only way. Don't tell me you will
> implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in 
> assembly... 

Until not that long ago, an embedded system with that much stuff would
have been considered high end.  Mid-end would be something capable of
running interactive Forth, e.g. Atmega128 or so.  Low end would be a
tiny PIC with a 0.5k of code space and few dozen bytes of ram.

I wonder if Forth was even ever intended to write systems of that
complexity.  Remember Chuck's adage that 1000 instructions is enough to
write any program.  I doubt that the NRAO system had tcp/ip stacks, USB
stacks, wireless, etc.

Elizabeth if you're here: this may have come up before, but do you
remember about how much total Forth code went into the Saudi airport
system?

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

#47431

From	Ron Aaron <rambamist@gmail.com>
Date	2016-05-23 07:03 +0300
Message-ID	<nhtv85$q0c$1@dont-email.me>
In reply to	#47430

On 05/23/2016 06:38, Paul Rubin wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> For mid-end embedded systems C is the only way. Don't tell me you will
>> implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in 
>> assembly... 
> 
> Until not that long ago, an embedded system with that much stuff would
> have been considered high end.  Mid-end would be something capable of
> running interactive Forth, e.g. Atmega128 or so.  Low end would be a
> tiny PIC with a 0.5k of code space and few dozen bytes of ram.

Yes, and I think that's the point.  Now you do have systems that
complex, and you are almost certainly not writing all the bits and
pieces yourself -- and those you don't are probably not written in
Forth, these days.

> I wonder if Forth was even ever intended to write systems of that
> complexity.  Remember Chuck's adage that 1000 instructions is enough to
> write any program.  I doubt that the NRAO system had tcp/ip stacks, USB
> stacks, wireless, etc.

That's a good question, though I don't think there's any reason to
assume Forth is less good a solution for complex systems than C has
been.  History has not been kind to Forth, but that's the way the cookie
crumbles.

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

#47437

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-05-22 21:22 -1000
Message-ID	<VZydnTeRYa4jMt_KnZ2dnUU7-UHNnZ2d@supernews.com>
In reply to	#47431

On 5/22/16 6:03 PM, Ron Aaron wrote:
>
>
> On 05/23/2016 06:38, Paul Rubin wrote:
>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>> For mid-end embedded systems C is the only way. Don't tell me you will
>>> implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in
>>> assembly...
>>
>> Until not that long ago, an embedded system with that much stuff would
>> have been considered high end.  Mid-end would be something capable of
>> running interactive Forth, e.g. Atmega128 or so.  Low end would be a
>> tiny PIC with a 0.5k of code space and few dozen bytes of ram.
>
> Yes, and I think that's the point.  Now you do have systems that
> complex, and you are almost certainly not writing all the bits and
> pieces yourself -- and those you don't are probably not written in
> Forth, these days.
>
>> I wonder if Forth was even ever intended to write systems of that
>> complexity.  Remember Chuck's adage that 1000 instructions is enough to
>> write any program.  I doubt that the NRAO system had tcp/ip stacks, USB
>> stacks, wireless, etc.
>
> That's a good question, though I don't think there's any reason to
> assume Forth is less good a solution for complex systems than C has
> been.  History has not been kind to Forth, but that's the way the cookie
> crumbles.

The thing is, even very complex systems can be factored into components 
that are tractable. And there's quite a lot of Forth code around in the 
back pockets of companies and individuals who have been doing this for 
years. There are TCP/IP stacks, USB stacks, and wireless communications 
in applications around, they just haven't all been productized and 
published except as add-ons for the commercial systems. The main reason 
is that it is so easy to take the software you optimized for Project X 
and use it in Project Y even though they differ in requirements somewhat.

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]

#47464

From	hughaguilar96@gmail.com
Date	2016-05-23 23:21 -0700
Message-ID	<b4e534fc-34f1-4bb6-bff5-ba5a3fb98685@googlegroups.com>
In reply to	#47437

On Monday, May 23, 2016 at 12:22:39 AM UTC-7, Elizabeth D. Rather wrote:
> On 5/22/16 6:03 PM, Ron Aaron wrote:
> >
> >
> > On 05/23/2016 06:38, Paul Rubin wrote:
> >> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >>> For mid-end embedded systems C is the only way. Don't tell me you will
> >>> implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in
> >>> assembly...
> >>
> >> Until not that long ago, an embedded system with that much stuff would
> >> have been considered high end.  Mid-end would be something capable of
> >> running interactive Forth, e.g. Atmega128 or so.  Low end would be a
> >> tiny PIC with a 0.5k of code space and few dozen bytes of ram.
> >
> > Yes, and I think that's the point.  Now you do have systems that
> > complex, and you are almost certainly not writing all the bits and
> > pieces yourself -- and those you don't are probably not written in
> > Forth, these days.
> >
> >> I wonder if Forth was even ever intended to write systems of that
> >> complexity.  Remember Chuck's adage that 1000 instructions is enough to
> >> write any program.  I doubt that the NRAO system had tcp/ip stacks, USB
> >> stacks, wireless, etc.
> >
> > That's a good question, though I don't think there's any reason to
> > assume Forth is less good a solution for complex systems than C has
> > been.  History has not been kind to Forth, but that's the way the cookie
> > crumbles.
> 
> The thing is, even very complex systems can be factored into components 
> that are tractable. And there's quite a lot of Forth code around in the 
> back pockets of companies and individuals who have been doing this for 
> years. There are TCP/IP stacks, USB stacks, and wireless communications 
> in applications around, they just haven't all been productized and 
> published except as add-ons for the commercial systems. The main reason 
> is that it is so easy to take the software you optimized for Project X 
> and use it in Project Y even though they differ in requirements somewhat.

This is pure fantasy --- there is no TCP/IP stack in anybody's back pocket.

Here is an exchange we had previously:
Elizabeth Rather:           
Since it's so easy to write common procedures in Forth, they tend to be 
tightly adapted to the application for which they're developed,
which makes them less amenable to sharing.

Anton Ertl question:        
Why do other languages have a thriving culture of sharing reusable code and 
Forth doesn't? One of the reasons is that the idea of code
reuse is despised by a significant part of the Forth community, according to 
lore starting with Charles Moore.

Elizabeth Rather response:  
That is not entirely true. Chuck carried around with him a large library of 
things he had written in the past (in the 70's, a notebook
full of microfiches and a reader!), and always started with past code when he 
could. Of course, then he re-wrote it for the application
at hand (see my last point above). And everyone I know who is spending a 
career writing Forth applications has a bulging "back pocket"
of reusable code. FORTH, Inc., MPE, and probably most other widely used 
systems have such libraries.

Elizabeth Rather just doesn't understand the concept of reusable general-purpose code-libraries. She is totally focused on cut-and-paste of old programs' code into new programs --- this is not the way that professional software is written however --- this is why ANS-Forth is considered to be a toy language used only in toy programs.

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

#47472

From	stephen@mpeforth.com (Stephen Pelc)
Date	2016-05-24 09:36 +0000
Message-ID	<57442028.484729691@news.eternal-september.org>
In reply to	#47464

On Mon, 23 May 2016 23:21:40 -0700 (PDT), hughaguilar96@gmail.com
wrote:

>This is pure fantasy --- there is no TCP/IP stack in anybody's back pocket.

http://www.mpeforth.com/powernet.htm

It's been available for over 15 years.

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]

#47480

From	foxaudioresearch@gmail.com
Date	2016-05-24 08:02 -0700
Message-ID	<01121fac-3425-4749-ab1a-d7cec0bb89c6@googlegroups.com>
In reply to	#47472

On Tuesday, May 24, 2016 at 5:36:49 AM UTC-4, Stephen Pelc wrote:
> On Mon, 23 May 2016 23:21:40 -0700 (PDT), hughaguilar96@gmail.com
> wrote:
> 
> >This is pure fantasy --- there is no TCP/IP stack in anybody's back pocket.
> 
> http://www.mpeforth.com/powernet.htm
> 
> It's been available for over 15 years.
> 
> 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

From the MPE Website:

"Small memory footprint
... A full build on an ARM including the Forth open 
interpreter/compiler, RTOS support, three serial drivers, Ethernet driver, UDP 
and TCP, and Echo, Telnet and HTTP (with ASP, CGI and ForthScript) servers 
requires 116kb of ROM. From version 4, RAM usage has been reduced so that a 
complete Forth system with Ethernet, Telnet and a web server requires less than
 16kb of RAM."

Out of curiosity, does anybody know how much space these services take when
written in other languages? I should think Forth is able to show well int
that regard.

BF

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

#47481

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-24 15:34 +0000
Message-ID	<2016May24.173412@mips.complang.tuwien.ac.at>
In reply to	#47480

foxaudioresearch@gmail.com writes:
>From the MPE Website:
>
>"Small memory footprint
>... A full build on an ARM including the Forth open 
>interpreter/compiler, RTOS support, three serial drivers, Ethernet driver, UDP 
>and TCP, and Echo, Telnet and HTTP (with ASP, CGI and ForthScript) servers 
>requires 116kb of ROM. From version 4, RAM usage has been reduced so that a 
>complete Forth system with Ethernet, Telnet and a web server requires less than
> 16kb of RAM."
>
>Out of curiosity, does anybody know how much space these services take when
>written in other languages?

[panda:~:41133] file /usr/bin/telnet.netkit
/usr/bin/telnet.netkit: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0x76dac7af86b69a736a3983f404f0592fb142ca19, stripped
[panda:~:41134] size /usr/bin/telnet.netkit
   text    data     bss     dec     hex filename
  51506    4888    5864   62258    f332 /usr/bin/telnet.netkit

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#47507

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-05-25 05:43 -0500
Message-ID	<VPqdnQUcQYMqHNjKnZ2dnUU7-e_NnZ2d@supernews.com>
In reply to	#47481

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> foxaudioresearch@gmail.com writes:
>>From the MPE Website:
>>
>>"Small memory footprint
>>... A full build on an ARM including the Forth open 
>>interpreter/compiler, RTOS support, three serial drivers, Ethernet driver, UDP 
>>and TCP, and Echo, Telnet and HTTP (with ASP, CGI and ForthScript) servers 
>>requires 116kb of ROM. From version 4, RAM usage has been reduced so that a 
>>complete Forth system with Ethernet, Telnet and a web server requires less than
>> 16kb of RAM."
>>
>>Out of curiosity, does anybody know how much space these services take when
>>written in other languages?
> 
> [panda:~:41133] file /usr/bin/telnet.netkit
> /usr/bin/telnet.netkit: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0x76dac7af86b69a736a3983f404f0592fb142ca19, stripped
> [panda:~:41134] size /usr/bin/telnet.netkit
>   text    data     bss     dec     hex filename
>  51506    4888    5864   62258    f332 /usr/bin/telnet.netkit

Umm, I don't get it.  Surely the TCP/IP stack is in the kernel.
telnet is a thin protocol on top of that.  Or does telnet.netkit
contain all of user mode Linux's kernel networking?

Andrew.

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

#47509

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-25 13:43 +0000
Message-ID	<2016May25.154328@mips.complang.tuwien.ac.at>
In reply to	#47507

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> foxaudioresearch@gmail.com writes:
>>>From the MPE Website:
>>>
>>>"Small memory footprint
>>>... A full build on an ARM including the Forth open 
>>>interpreter/compiler, RTOS support, three serial drivers, Ethernet driver, UDP 
>>>and TCP, and Echo, Telnet and HTTP (with ASP, CGI and ForthScript) servers 
>>>requires 116kb of ROM. From version 4, RAM usage has been reduced so that a 
>>>complete Forth system with Ethernet, Telnet and a web server requires less than
>>> 16kb of RAM."
>>>
>>>Out of curiosity, does anybody know how much space these services take when
>>>written in other languages?
>> 
>> [panda:~:41133] file /usr/bin/telnet.netkit
>> /usr/bin/telnet.netkit: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0x76dac7af86b69a736a3983f404f0592fb142ca19, stripped
>> [panda:~:41134] size /usr/bin/telnet.netkit
>>   text    data     bss     dec     hex filename
>>  51506    4888    5864   62258    f332 /usr/bin/telnet.netkit
>
>Umm, I don't get it.  Surely the TCP/IP stack is in the kernel.
>telnet is a thin protocol on top of that.  Or does telnet.netkit
>contain all of user mode Linux's kernel networking?

I think it just contains Telnet.

I looked at the lsmod output, but did not find modules for (wired)
Ethernet or TCP/IP there (they are probably compiled hard into the
kernel).  I also considered looking at the size of a web server like
Apache (and it's modules), but web servers vary a lot, not just in
size, but also in capability, so I skipped that part.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

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

#47484

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-05-24 09:40 -0700
Message-ID	<87a8jfh0iy.fsf@jester.gateway.pace.com>
In reply to	#47480

foxaudioresearch@gmail.com writes:
> Out of curiosity, does anybody know how much space these services take when
> written in other languages? I should think Forth is able to show well int
> that regard.

From https://en.wikipedia.org/wiki/LwIP :

    The focus of the lwIP TCP/IP implementation is to reduce resource usage
    while still having a full-scale TCP.[3] This makes lwIP suitable for use
    in embedded systems with tens of kilobytes of free RAM and room for
    around 40 kilobytes of code ROM.

That 40k includes fewer services than Powernet so the numbers aren't
directly comparable.  On the other hand, I believe it supports ipv6.  If
not, the related uip (micro IP) does.  Powernet's web page doesn't
mention whether Powernet does as well.

There are additionally a number of small (50k-ish) TLS stacks written in
C.  I don't know if one has ever been done in Forth.

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

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

csiph-web

Was just wondering when people started using C to write forth languages and not assembly?

Contents

#47312

#47339

#47341

#47342

#47344

#47345

#47360

#47411

#47444 — Re: Was just wondering when people started using C to write forthlanguages and not assembly?

#47367

#47430

#47431

#47437

#47464

#47472

#47480

#47481

#47507

#47509

#47484