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

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

esp8266 eForth and it's development software

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

Contents

  esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 15:18 -0600
    Re: esp8266 eForth and it's development software David Schultz <abuse@127.0.0.1> - 2017-03-01 15:29 -0600
      Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 17:16 -0600
        Re: esp8266 eForth and it's development software David Schultz <abuse@127.0.0.1> - 2017-03-01 17:51 -0600
          Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 18:36 -0600
            Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-01 16:53 -0800
              Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 19:28 -0600
                Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-01 17:56 -0800
                  Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 20:53 -0600
                    Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-01 18:57 -0800
                      Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 21:17 -0600
                        Re: esp8266 eForth and it's development software David Schultz <abuse@127.0.0.1> - 2017-03-01 21:38 -0600
                          Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 22:02 -0600
                        Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-01 19:40 -0800
                          Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 22:44 -0600
    Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-01 14:50 -0800
      Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 17:26 -0600
        Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-01 15:41 -0800
        Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 18:10 -0600
    Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-04 20:50 -0600
      Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-04 20:10 -0800
        Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-04 23:06 -0600
          Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-04 21:25 -0800
            Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-05 00:47 -0600
              Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-05 01:36 -0800
                Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-05 17:11 -0600
                Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-05 15:43 -0600
              Re: esp8266 eForth and it's development software Mark Wills <markwills1970@gmail.com> - 2017-03-06 01:45 -0800
                Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-06 10:44 -0600
                Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-06 12:28 -0600
                  Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-06 16:00 -0600
                  Re: esp8266 eForth and it's development software Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-06 17:57 -0500
                    Re: esp8266 eForth and it's development software Mark Wills <markwills1970@gmail.com> - 2017-03-07 01:23 -0800
                      Re: esp8266 eForth and it's development software albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-07 12:32 +0100
                      Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-07 10:39 -0600
    Re: esp8266 eForth and it's development software albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-06 13:35 +0100
      Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-06 10:51 -0600
        Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-07 22:33 -0600
          Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-07 20:39 -0800
            Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-07 23:42 -0600
              Re: esp8266 eForth and it's development software Paul Rubin <no.email@nospam.invalid> - 2017-03-07 23:44 -0800
                Re: esp8266 eForth and it's development software Cecil Bayona <cbayona@cbayona.com> - 2017-03-08 11:03 -0600
            Re: esp8266 eForth and it's development software albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-08 12:05 +0100
      Re: esp8266 eForth and it's development software anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-06 17:09 +0000
        Re: esp8266 eForth and it's development software albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-07 12:52 +0100

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

#55415

Cecil Bayona <cbayona@cbayona.com> writes:
> Tomorrow I'll start converting the Arduino code to C which hopefully
> should not be too hard then start debugging it on a Nucleo F401 board,
> which has plenty of FLASH and RAM.

If you just want an eforth-ish interpreter written in C, try this:

  http://chiselapp.com/user/tehologist/repository/compc/home

It might be interesting to make the backend generate machine code
instead of VM code.

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

#55417

On 3/4/2017 10:10 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> Tomorrow I'll start converting the Arduino code to C which hopefully
>> should not be too hard then start debugging it on a Nucleo F401 board,
>> which has plenty of FLASH and RAM.
>
> If you just want an eforth-ish interpreter written in C, try this:
>
>   http://chiselapp.com/user/tehologist/repository/compc/home
>
> It might be interesting to make the backend generate machine code
> instead of VM code.
>

  Right now I know this code that I have works and it's very simple so I 
want to make it better, more efficient and faster, and along the way get 
a refresher in C, I have not used C in a while so I need to get my feet 
wet again.

Thanks for the link, I was thinking of a similar thing down the line, to 
have the C code generate machine language, but that will be for a little 
later maybe in a month or two. I'm sure it's been done many times but 
eventually I wanted something more complex than a simple VM in C that 
tends to be inefficient, but instead more of the Forth machine in C and 
have it generate machine code for higher speed but be Forth like in 
behavior.


-- 
Cecil - k5nwa

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

#55418

Cecil Bayona <cbayona@cbayona.com> writes:
> I want to make it better, more efficient and faster,

Can I ask if you have a particular application for which the existing
implementation is too slow?  There definitely times when I care how fast
my own code runs.  Most of the time though, I don't care, in the sense
that it's already fast enough when done in a dumb and not-so-efficient
way, that I wouldn't gain any practical benefit by working to speed it
up more.

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

#55419

On 3/4/2017 11:25 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> I want to make it better, more efficient and faster,
>
> Can I ask if you have a particular application for which the existing
> implementation is too slow?  There definitely times when I care how fast
> my own code runs.  Most of the time though, I don't care, in the sense
> that it's already fast enough when done in a dumb and not-so-efficient
> way, that I wouldn't gain any practical benefit by working to speed it
> up more.
>

Nothing specific at the moment but efficient doesn't hurt, some of the 
code is pretty bad and easily speeded up while still being a generic 
forth system that can be compiled to any embedded CPU that has a C compiler.

-- 
Cecil - k5nwa

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

#55424

Cecil Bayona <cbayona@cbayona.com> writes:
> Nothing specific at the moment but efficient doesn't hurt

Fair enough, but it would be interesting to compare against micropython
or Duktape (micro javascript) or Lua (NodeMCU) or other HLL's that have
gotten popular on the 8266.  Forth was traditionally implemented as ITC
with some code words at the bottom, so it took maybe a 10x speed hit
compared to assembler, making it far superior to alternatives like
BASIC.  Do you think what you're using now is worse than a traditional
ITC?

In short I wouldn't worry about the interpreter speed until you hit a
problem where it's a practical obstacle.

Also aren't there lots of small portable Forth-in-C implementations like
pForth?  Or the 8266 might even be able to run Gforth-embedded.  The
ESP32 is even more likely to be able to.

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

#55432

On 3/5/2017 3:36 AM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> Nothing specific at the moment but efficient doesn't hurt
>
> Fair enough, but it would be interesting to compare against micropython
> or Duktape (micro javascript) or Lua (NodeMCU) or other HLL's that have
> gotten popular on the 8266.  Forth was traditionally implemented as ITC
> with some code words at the bottom, so it took maybe a 10x speed hit
> compared to assembler, making it far superior to alternatives like
> BASIC.  Do you think what you're using now is worse than a traditional
> ITC?
>

For now I will stop working on the espxxxx family and work with ARM and 
MSP430 for which I have decent compilers available, work with those 
tools to make the VM more efficient, while keeping an eye on the espxxxx 
tools and see if they improve. Right now GCC for the esp8266 generates 
terrible code, dozens of instructions for very simple C code while 
Rowley generates much better code for the ARM and MSP430.

I think so, in-between every executed forth primitive, fetch there is a 
call to check on the WiFi, that would be hundreds if not thousands of 
instructions for every Forth primitive. With the WiFi the esp32 would be 
much better as there is a CPU dedicated to the WiFi so the main CPU 
doesn't have to share so often. Also every time you address memory to 
fetch instructions, fetch or store data there are address calculations 
made that includes division that is grossly inefficient.

> In short I wouldn't worry about the interpreter speed until you hit a
> problem where it's a practical obstacle.

I'm retired, I like to keep busy, this looks like a fun project to do. 
Its an opportunity to get re-acquainted with C again, and I have not 
been utilizing Rowley's tools very much which are excellent and might be 
useful for other projects.

  Looking at the basics there, it looks like it could also be the basics 
for a Forth emulator for Windows that might be useful to a beginner to 
see what is going on inside a Forth VM as one single steps through a 
program, but that is not a high priority for me at the moment.
>
> Also aren't there lots of small portable Forth-in-C implementations like
> pForth?  Or the 8266 might even be able to run Gforth-embedded.  The
> ESP32 is even more likely to be able to.
>

I'm sure there are, I have seen plenty but I have not paid attention, I 
looked at some and they were overly complicated, this eForth project is 
so simple which makes it easy to work with. I own a copy of iForth and 
excellent optimizing Forth compiler that also comes with simpler 
versions so eventually I can look at them for ideas. Right now I want to 
concentrate at simple but efficient, then later we can look at other 
options once I'm comfortable with the tools again.


-- 
Cecil - k5nwa

-- 
Cecil - k5nwa

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

#55435

On 3/5/2017 3:36 AM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> Nothing specific at the moment but efficient doesn't hurt
>
> Fair enough, but it would be interesting to compare against micropython
> or Duktape (micro javascript) or Lua (NodeMCU) or other HLL's that have
> gotten popular on the 8266.  Forth was traditionally implemented as ITC
> with some code words at the bottom, so it took maybe a 10x speed hit
> compared to assembler, making it far superior to alternatives like
> BASIC.  Do you think what you're using now is worse than a traditional
> ITC?
>

For now I will stop working on the espxxxx family and work with ARM and 
MSP430 for which I have decent compilers available, work with those 
tools to make the VM more efficient, while keeping an eye on the espxxxx 
tools and see if they improve. Right now GCC for the esp8266 generates 
terrible code, dozens of instructions for very simple C code while 
Rowley generates much better code for the ARM and MSP430.

I think so, in-between every executed forth primitive, fetch there is a 
call to check on the WiFi, that would be hundreds if not thousands of 
instructions for every Forth primitive. With the WiFi the esp32 would be 
much better as there is a CPU dedicated to the WiFi so the main CPU 
doesn't have to share so often. Also every time you address memory to 
fetch instructions, fetch or store data there are address calculations 
made that includes division that is grossly inefficient.

> In short I wouldn't worry about the interpreter speed until you hit a
> problem where it's a practical obstacle.

I'm retired, I like to keep busy, this looks like a fun project to do. 
Its an opportunity to get re-acquainted with C again, and I have not 
been utilizing Rowley's tools very much which are excellent and might be 
useful for other projects.

  Looking at the basics there, it looks like it could also be the basics 
for a Forth emulator for Windows that might be useful to a beginner to 
see what is going on inside a Forth VM as one single steps through a 
program, but that is not a high priority for me at the moment.
>
> Also aren't there lots of small portable Forth-in-C implementations like
> pForth?  Or the 8266 might even be able to run Gforth-embedded.  The
> ESP32 is even more likely to be able to.
>

I'm sure there are, I have seen plenty but I have not paid attention, I 
looked at some and they were overly complicated, this eForth project is 
so simple which makes it easy to work with. I own a copy of iForth and 
excellent optimizing Forth compiler that also comes with simpler 
versions so eventually I can look at them for ideas. Right now I want to 
concentrate at simple but efficient, then later we can look at other 
options once I'm comfortable with the tools again.


-- 
Cecil - k5nwa

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

#55448

On Sunday, 5 March 2017 06:47:01 UTC, Cecil - k5nwa  wrote:
> On 3/4/2017 11:25 PM, Paul Rubin wrote:
> > Cecil Bayona <cbayona@cbayona.com> writes:
> >> I want to make it better, more efficient and faster,
> >
> > Can I ask if you have a particular application for which the existing
> > implementation is too slow?  There definitely times when I care how fast
> > my own code runs.  Most of the time though, I don't care, in the sense
> > that it's already fast enough when done in a dumb and not-so-efficient
> > way, that I wouldn't gain any practical benefit by working to speed it
> > up more.
> >
> 
> Nothing specific at the moment but efficient doesn't hurt, some of the 
> code is pretty bad and easily speeded up while still being a generic 
> forth system that can be compiled to any embedded CPU that has a C compiler.
> 
> -- 
> Cecil - k5nwa

Indeed. If some of the improvements are 'easy wins' then why not?

You mentioned a version that produces machine code. Do you have any 
plans to use it on the MSP430?

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

#55464

On 3/6/2017 3:45 AM, Mark Wills wrote:
> On Sunday, 5 March 2017 06:47:01 UTC, Cecil - k5nwa  wrote:
>> On 3/4/2017 11:25 PM, Paul Rubin wrote:
>>> Cecil Bayona <cbayona@cbayona.com> writes:
>>>> I want to make it better, more efficient and faster,
>>>
>>> Can I ask if you have a particular application for which the existing
>>> implementation is too slow?  There definitely times when I care how fast
>>> my own code runs.  Most of the time though, I don't care, in the sense
>>> that it's already fast enough when done in a dumb and not-so-efficient
>>> way, that I wouldn't gain any practical benefit by working to speed it
>>> up more.
>>>
>>
>> Nothing specific at the moment but efficient doesn't hurt, some of the
>> code is pretty bad and easily speeded up while still being a generic
>> forth system that can be compiled to any embedded CPU that has a C compiler.
>>
>> --
>> Cecil - k5nwa
>
> Indeed. If some of the improvements are 'easy wins' then why not?
>
> You mentioned a version that produces machine code. Do you have any
> plans to use it on the MSP430?
>
Later today I will start converting the Arduino source to Rowley's C, 
the hardest part of a project is getting started.

I don't know at this point about the MSP430, I like the processor but as 
I have a couple of decent Forth compilers for the MSP430 that generated 
machine code, I have a eForth, and MPE Professional Cross Compiler for 
MSP430 among some of my toys.

Dr Ting did some experiment and he concluded that subroutine linked was 
not as efficient as direct threading on the MSP430 by I don't know how 
he judged it. I tend to think his priority was code size not speed since 
he did it on a MSP430G2553 device which has limited FLASH capacity (16K 
FLASH).

I have too many projects going on, at present a C Forth compiler that 
generates machine code is down on my list but not horribly down, but if 
I did one the first target would be the espxx family of devices, GCC is 
terrible at present so the eForth I have for the esp8266 is not so good. 
It could be the CPU itself having a crummy instruction set. After a 
quick look at the instruction set I tend to think that it's a first pass 
at the compiler with little optimization but I'm not 100% sure.


-- 
Cecil - k5nwa

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

#55472

On 3/6/2017 3:45 AM, Mark Wills wrote:
> On Sunday, 5 March 2017 06:47:01 UTC, Cecil - k5nwa  wrote:
>> On 3/4/2017 11:25 PM, Paul Rubin wrote:
>>> Cecil Bayona <cbayona@cbayona.com> writes:
>>>> I want to make it better, more efficient and faster,
>>>
>>> Can I ask if you have a particular application for which the existing
>>> implementation is too slow?  There definitely times when I care how fast
>>> my own code runs.  Most of the time though, I don't care, in the sense
>>> that it's already fast enough when done in a dumb and not-so-efficient
>>> way, that I wouldn't gain any practical benefit by working to speed it
>>> up more.
>>>
>>
>> Nothing specific at the moment but efficient doesn't hurt, some of the
>> code is pretty bad and easily speeded up while still being a generic
>> forth system that can be compiled to any embedded CPU that has a C compiler.
>>
>> --
>> Cecil - k5nwa
>
> Indeed. If some of the improvements are 'easy wins' then why not?
>
> You mentioned a version that produces machine code. Do you have any
> plans to use it on the MSP430?
>

I just had a good laugh, I looked through my bookshelf to see what books 
I have on C programming, one book, Kernighan and Ritchie's "The C 
Programming Language". I have tons of books on various programming 
subjects such as data structures, sorting, and other programming task 
but they are not C books Other books on languages such as MatLab, 
Delphi, Prolog, .Net Languages such as C#, VB.NET, PHP, and other 
languages including Forth, but one book on C, "The Book" on C, the 
language reference by the creators of C.

It says something about C, how simple it is, that one book was all I 
felt I ever needed. But the language is a bear when you have pointer 
errors because anything is basically allowed, now you have lint to find 
unassigned pointers and such. That was one reason why I started using 
Pascal and Delphi a long time ago. But Forth is on the same boat, 
anything goes, no checking by the compiler.

I'll have to look later on Amazon when I get back from running errands 
but I have a feeling there is little else I will need on the language.

Time for some fun later tonight.

-- 
Cecil - k5nwa

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

#55479

On 3/6/2017 12:28 PM, Cecil Bayona wrote:
> On 3/6/2017 3:45 AM, Mark Wills wrote:
>> On Sunday, 5 March 2017 06:47:01 UTC, Cecil - k5nwa  wrote:
>>> On 3/4/2017 11:25 PM, Paul Rubin wrote:
>>>> Cecil Bayona <cbayona@cbayona.com> writes:
>>>>> I want to make it better, more efficient and faster,
>>>>
>>>> Can I ask if you have a particular application for which the existing
>>>> implementation is too slow?  There definitely times when I care how
>>>> fast
>>>> my own code runs.  Most of the time though, I don't care, in the sense
>>>> that it's already fast enough when done in a dumb and not-so-efficient
>>>> way, that I wouldn't gain any practical benefit by working to speed it
>>>> up more.
>>>>
>>>
>>> Nothing specific at the moment but efficient doesn't hurt, some of the
>>> code is pretty bad and easily speeded up while still being a generic
>>> forth system that can be compiled to any embedded CPU that has a C
>>> compiler.
>>>
>>> --
>>> Cecil - k5nwa
>>
>> Indeed. If some of the improvements are 'easy wins' then why not?
>>
>> You mentioned a version that produces machine code. Do you have any
>> plans to use it on the MSP430?
>>
>
> I just had a good laugh, I looked through my bookshelf to see what books
> I have on C programming, one book, Kernighan and Ritchie's "The C
> Programming Language". I have tons of books on various programming
> subjects such as data structures, sorting, and other programming task
> but they are not C books Other books on languages such as MatLab,
> Delphi, Prolog, .Net Languages such as C#, VB.NET, PHP, and other
> languages including Forth, but one book on C, "The Book" on C, the
> language reference by the creators of C.
>
> It says something about C, how simple it is, that one book was all I
> felt I ever needed. But the language is a bear when you have pointer
> errors because anything is basically allowed, now you have lint to find
> unassigned pointers and such. That was one reason why I started using
> Pascal and Delphi a long time ago. But Forth is on the same boat,
> anything goes, no checking by the compiler.
>
> I'll have to look later on Amazon when I get back from running errands
> but I have a feeling there is little else I will need on the language.
>
> Time for some fun later tonight.
>


When I go to Amazon looking for books soon my money is parting from me, 
I found several books that I was willing to buy, including several on 
data structures using C so now I have a modest library on the Language 
C, 10 eBooks to be precise.

A funny thing is the the K&R C book cast more as an eBook ($35) than as 
a brand new book that is hard bound ($20) by over 50%, too bad I would 
not have minded having a computer readable copy.

-- 
Cecil - k5nwa

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

#55480

On Mon, 6 Mar 2017 12:28:46 -0600
Cecil Bayona <cbayona@cbayona.com> wrote:

> On 3/6/2017 3:45 AM, Mark Wills wrote:

> I just had a good laugh, I looked through my bookshelf to see what
> books I have on C programming, one book, Kernighan and Ritchie's "The
> C Programming Language". I have tons of books on various programming 
> subjects such as data structures, sorting, and other programming task 
> but they are not C books Other books on languages such as MatLab, 
> Delphi, Prolog, .Net Languages such as C#, VB.NET, PHP, and other 
> languages including Forth, but one book on C, "The Book" on C, the 
> language reference by the creators of C.
>
> It says something about C, how simple it is, that one book was all I 
> felt I ever needed. But the language is a bear when you have pointer 
> errors because anything is basically allowed, now you have lint to
> find unassigned pointers and such. 

I beg to differ.  "THE Book" on C is *NOT* Kernighan and Ritchie's "The
C Programming Language."  That's only an introduction to C.  Far and
away the absolute best book on C that exists is "C: A Reference Manual"
by Samuel P. Harbison and Guy L. Steele, Jr. of Tartan Laboratories.
It's truly the only book on C you'll ever need.  Another good book is
"The Standard C Library" by P.J. Plauger.  These are the only two books
in my library of C books that were worth the money.  They are the only
two that I've consistently used for a few decades now.  If you ask on
comp.lang.c, they'll tell you that you need "C Unleashed" since a bunch
of the people who posted to the Usenet group circa year 2000 wrote it,
such as Richard Heathfield, Lawrence Kirby, and something like 15
others.  Personally, I wouldn't suggest anyone spend money on this book
either.


Rod Pemberton
-- 
All it takes for humanity to conquer the world's toughest problems
is to hope, to believe, to share, and to do, in cooperation.

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

#55488

On Monday, 6 March 2017 22:56:22 UTC, Rod Pemberton  wrote:
> On Mon, 6 Mar 2017 12:28:46 -0600
> Cecil Bayona <cbayona@cbayona.com> wrote:
> 
> > On 3/6/2017 3:45 AM, Mark Wills wrote:
> 
> > I just had a good laugh, I looked through my bookshelf to see what
> > books I have on C programming, one book, Kernighan and Ritchie's "The
> > C Programming Language". I have tons of books on various programming 
> > subjects such as data structures, sorting, and other programming task 
> > but they are not C books Other books on languages such as MatLab, 
> > Delphi, Prolog, .Net Languages such as C#, VB.NET, PHP, and other 
> > languages including Forth, but one book on C, "The Book" on C, the 
> > language reference by the creators of C.
> >
> > It says something about C, how simple it is, that one book was all I 
> > felt I ever needed. But the language is a bear when you have pointer 
> > errors because anything is basically allowed, now you have lint to
> > find unassigned pointers and such. 
> 
> I beg to differ.  "THE Book" on C is *NOT* Kernighan and Ritchie's "The
> C Programming Language."  That's only an introduction to C.  Far and
> away the absolute best book on C that exists is "C: A Reference Manual"
> by Samuel P. Harbison and Guy L. Steele, Jr. of Tartan Laboratories.
> It's truly the only book on C you'll ever need.  Another good book is
> "The Standard C Library" by P.J. Plauger.  These are the only two books
> in my library of C books that were worth the money.  They are the only
> two that I've consistently used for a few decades now.  If you ask on
> comp.lang.c, they'll tell you that you need "C Unleashed" since a bunch
> of the people who posted to the Usenet group circa year 2000 wrote it,
> such as Richard Heathfield, Lawrence Kirby, and something like 15
> others.  Personally, I wouldn't suggest anyone spend money on this book
> either.
> 
> 
> Rod Pemberton
> -- 
> All it takes for humanity to conquer the world's toughest problems
> is to hope, to believe, to share, and to do, in cooperation.

Yes. I found the K&R book too terse when I read it (very early 90s). I was just
learning C, there was no internet (that I or anyone I knew had access to)
and I was pretty much on my own. In those days you went to the library to
find stuff out.

It kind of left me with a bad feeling when it comes to C. That and some
horrifically complicated C code that I once got involved with
that was written by a black-belt ninja C guru type bloke. We would pontificate
if he deliberately wrote obtuse C code when he wasn't in the room. It was
was really hard to follow, and he was an obnoxious bastard. Everyone was 
afraid to ask him anything for fear of ridicule. It the was pointer syntax
that I always struggled with in C. Everything else seemed quite nice.
Simple pointers are okay, pointers to structs etc, yeah I was okay with that. It was when you started to get into double indirection (pointers to pointers) that it got tricky!

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

#55492

In article <893d7a04-cde5-4ca2-9d7d-5c3e95172e94@googlegroups.com>,
Mark Wills  <markwills1970@gmail.com> wrote:
>On Monday, 6 March 2017 22:56:22 UTC, Rod Pemberton  wrote:
>> On Mon, 6 Mar 2017 12:28:46 -0600
>> Cecil Bayona <cbayona@cbayona.com> wrote:
>>
>> > On 3/6/2017 3:45 AM, Mark Wills wrote:
>>
>> > I just had a good laugh, I looked through my bookshelf to see what
>> > books I have on C programming, one book, Kernighan and Ritchie's "The
>> > C Programming Language". I have tons of books on various programming
>> > subjects such as data structures, sorting, and other programming task
>> > but they are not C books Other books on languages such as MatLab,
>> > Delphi, Prolog, .Net Languages such as C#, VB.NET, PHP, and other
>> > languages including Forth, but one book on C, "The Book" on C, the
>> > language reference by the creators of C.
>> >
>> > It says something about C, how simple it is, that one book was all I
>> > felt I ever needed. But the language is a bear when you have pointer
>> > errors because anything is basically allowed, now you have lint to
>> > find unassigned pointers and such.
>>
>> I beg to differ.  "THE Book" on C is *NOT* Kernighan and Ritchie's "The
>> C Programming Language."  That's only an introduction to C.  Far and
>> away the absolute best book on C that exists is "C: A Reference Manual"
>> by Samuel P. Harbison and Guy L. Steele, Jr. of Tartan Laboratories.
>> It's truly the only book on C you'll ever need.  Another good book is
>> "The Standard C Library" by P.J. Plauger.  These are the only two books
>> in my library of C books that were worth the money.  They are the only
>> two that I've consistently used for a few decades now.  If you ask on
>> comp.lang.c, they'll tell you that you need "C Unleashed" since a bunch
>> of the people who posted to the Usenet group circa year 2000 wrote it,
>> such as Richard Heathfield, Lawrence Kirby, and something like 15
>> others.  Personally, I wouldn't suggest anyone spend money on this book
>> either.
>>
>>
>> Rod Pemberton
>> --
>> All it takes for humanity to conquer the world's toughest problems
>> is to hope, to believe, to share, and to do, in cooperation.
>
>Yes. I found the K&R book too terse when I read it (very early 90s). I was just
>learning C, there was no internet (that I or anyone I knew had access to)
>and I was pretty much on my own. In those days you went to the library to
>find stuff out.
>
>It kind of left me with a bad feeling when it comes to C. That and some
>horrifically complicated C code that I once got involved with
>that was written by a black-belt ninja C guru type bloke. We would pontificate
>if he deliberately wrote obtuse C code when he wasn't in the room. It was
>was really hard to follow, and he was an obnoxious bastard. Everyone was
>afraid to ask him anything for fear of ridicule. It the was pointer syntax
>that I always struggled with in C. Everything else seemed quite nice.
>Simple pointers are okay, pointers to structs etc, yeah I was okay with that. It was when you started to get into double indirection (pointers to pointers) that it got tricky!

I had the opposite experience with my C-guru, the man who wrote Edwin's
editor that I'm using right now. Everything he wrote looked so simple,
so straightforward that everyone could have done.

One anecdote. The administrator of our company wanted a database (for
clients or something). They wanted to do it in house, the estimate was
three months. They called it off. Then Edwin did it in a couple of
days. He had all kinds of functions keys to speed the typing,
this happens if I type <esc>Cm.

#include <stdio.h>

main(argc,argv)
int argc;
char **argv;
{

}


Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#55505

On 3/7/2017 3:23 AM, Mark Wills wrote:
> On Monday, 6 March 2017 22:56:22 UTC, Rod Pemberton  wrote:
>> On Mon, 6 Mar 2017 12:28:46 -0600
>> Cecil Bayona <cbayona@cbayona.com> wrote:
>>
>>> On 3/6/2017 3:45 AM, Mark Wills wrote:
>>
>>> I just had a good laugh, I looked through my bookshelf to see what
>>> books I have on C programming, one book, Kernighan and Ritchie's "The
>>> C Programming Language". I have tons of books on various programming
>>> subjects such as data structures, sorting, and other programming task
>>> but they are not C books Other books on languages such as MatLab,
>>> Delphi, Prolog, .Net Languages such as C#, VB.NET, PHP, and other
>>> languages including Forth, but one book on C, "The Book" on C, the
>>> language reference by the creators of C.
>>>
>>> It says something about C, how simple it is, that one book was all I
>>> felt I ever needed. But the language is a bear when you have pointer
>>> errors because anything is basically allowed, now you have lint to
>>> find unassigned pointers and such.
>>
>> I beg to differ.  "THE Book" on C is *NOT* Kernighan and Ritchie's "The
>> C Programming Language."  That's only an introduction to C.  Far and
>> away the absolute best book on C that exists is "C: A Reference Manual"
>> by Samuel P. Harbison and Guy L. Steele, Jr. of Tartan Laboratories.
>> It's truly the only book on C you'll ever need.  Another good book is
>> "The Standard C Library" by P.J. Plauger.  These are the only two books
>> in my library of C books that were worth the money.  They are the only
>> two that I've consistently used for a few decades now.  If you ask on
>> comp.lang.c, they'll tell you that you need "C Unleashed" since a bunch
>> of the people who posted to the Usenet group circa year 2000 wrote it,
>> such as Richard Heathfield, Lawrence Kirby, and something like 15
>> others.  Personally, I wouldn't suggest anyone spend money on this book
>> either.
>>
>>
>> Rod Pemberton
>> --
>> All it takes for humanity to conquer the world's toughest problems
>> is to hope, to believe, to share, and to do, in cooperation.
>
> Yes. I found the K&R book too terse when I read it (very early 90s). I was just
> learning C, there was no internet (that I or anyone I knew had access to)
> and I was pretty much on my own. In those days you went to the library to
> find stuff out.
>
> It kind of left me with a bad feeling when it comes to C. That and some
> horrifically complicated C code that I once got involved with
> that was written by a black-belt ninja C guru type bloke. We would pontificate
> if he deliberately wrote obtuse C code when he wasn't in the room. It was
> was really hard to follow, and he was an obnoxious bastard. Everyone was
> afraid to ask him anything for fear of ridicule. It the was pointer syntax
> that I always struggled with in C. Everything else seemed quite nice.
> Simple pointers are okay, pointers to structs etc, yeah I was okay with that. It was when you started to get into double indirection (pointers to pointers) that it got tricky!
>
My first experience with C was to write my own version of a C compiler, 
a difficult thing when you don't have a working C compiler, the initial 
code was written in PL/M and once enough of it started working translate 
that to C and self compile from then on. Quite a convoluted project, but 
I was young and had lots of energy, I also had AMD floating point chip 
to do floating point eventually. I was a recursive decent compiler and 
was pretty complete a couple of years later including a peephole 
optimizer, I wish I had kept the source. Much later Borland came up with 
a decent C compiler and that pretty much stopped further development on it.

I bought two more books to round out the library a hardbound copy of "C: 
A Reference Manual" and Plauger's Library book as an eBook. That is it 
for now, one hardbound book and eleven eBooks with about half no on C 
but on programming subjects, twelve books for around $70 shortly I will 
do the same for C++ but not on such a large scale maybe two to four 
books, I never have been a great fan of C++. At the time I looked at it 
it was hard to read compared to C and it generated not so fast code with 
it's emphasis on object oriented code.

I started creating a project to convert the eForth Arduino based VM to 
C, lots of errors but I had to quit as major storms were moving in with 
heavy thunderstorms and a Tornado Watch in effect.

-- 
Cecil - k5nwa

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

#55452

In article <o97do7$ru1$1@dont-email.me>,
Cecil Bayona  <cbayona@cbayona.com> wrote:
>Lately I've spent some time with C.H. Ting's eForth for the esp8266 and
>I been trying to improve it since I can see that some obvious
>improvements are possible but I'm having problems with the tools used.
>As an initial step I modified the code by making indenting, and function
>separations be consistent, I also been adding comments as to what is
>going on, I like the software I work with to be well documented
>
>The compiler uses code in C to create a eForth Virtual machine that
>executes 67 "eForth" primitives, but some of the code is less than
>optimal, for example the VM code that executes the next instruction,
>goes off on a eForth High Level subroutine, gets, or writes a byte or
>word calculates an address every single time, and it uses division as
>part of the process, very inefficient. It looks simple in C but the code
>generated is expensive in time.

I've looked at yforth in the Debian distribution.
That is a Forth written in c, but apparently by a good c-programmer.
The code is idiomatic and so allows a good c-compiler to do its job.
It will not, of course, help if you're fond of eForth-ism, but I
doubt there will much of that in a kernel.
A Forth in c must be written by a competent c-programmer. Being
a competent Forth programmer is hardly releveant.

I don't think that a SEARCH-WORDLIST written in c is less readable
then one written in Forth (actually the opposite) and once you go
the c-route and have it written out for you, why not use it?
There is little merit in writing @, DO and LOOP in c, and then use those
in write SEARCH-WORDLIST in Forth. (Maybe for SEE.)

I also see pforth in the Debian distribution. That looks like a
battle-hardened Forth, which has seen much practical use.
Is that the same as SPforth some people are talking about?

>Thanks
>--
>Cecil - k5nwa

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#55465

On 3/6/2017 6:35 AM, Albert van der Horst wrote:
> In article <o97do7$ru1$1@dont-email.me>,
> Cecil Bayona  <cbayona@cbayona.com> wrote:
>> Lately I've spent some time with C.H. Ting's eForth for the esp8266 and
>> I been trying to improve it since I can see that some obvious
>> improvements are possible but I'm having problems with the tools used.
>> As an initial step I modified the code by making indenting, and function
>> separations be consistent, I also been adding comments as to what is
>> going on, I like the software I work with to be well documented
>>
>> The compiler uses code in C to create a eForth Virtual machine that
>> executes 67 "eForth" primitives, but some of the code is less than
>> optimal, for example the VM code that executes the next instruction,
>> goes off on a eForth High Level subroutine, gets, or writes a byte or
>> word calculates an address every single time, and it uses division as
>> part of the process, very inefficient. It looks simple in C but the code
>> generated is expensive in time.
>
> I've looked at yforth in the Debian distribution.
> That is a Forth written in c, but apparently by a good c-programmer.
> The code is idiomatic and so allows a good c-compiler to do its job.
> It will not, of course, help if you're fond of eForth-ism, but I
> doubt there will much of that in a kernel.
> A Forth in c must be written by a competent c-programmer. Being
> a competent Forth programmer is hardly releveant.
>
> I don't think that a SEARCH-WORDLIST written in c is less readable
> then one written in Forth (actually the opposite) and once you go
> the c-route and have it written out for you, why not use it?
> There is little merit in writing @, DO and LOOP in c, and then use those
> in write SEARCH-WORDLIST in Forth. (Maybe for SEE.)
>
> I also see pforth in the Debian distribution. That looks like a
> battle-hardened Forth, which has seen much practical use.
> Is that the same as SPforth some people are talking about?
>
>> Thanks
>> --
>> Cecil - k5nwa
>
> Groetjes Albert
>
Thanks, I will look at the current crop of C Forths if I want to 
continue this process, the only reason I am working on this is because 
it's so simple so It could be useful in generating a Forth system for 
any CPU that has C. But I'm not a fan of C Forth everyone I seen is 
slower than a decent native version it's main advantage is portability.

To tell the truth a good part of the reason to work on this is that I 
have not used C in years and want to get used to it again, I did some 
major projects in C but that was a few years ago.

-- 
Cecil - k5nwa

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

#55520

On 3/6/2017 10:51 AM, Cecil Bayona wrote:
> On 3/6/2017 6:35 AM, Albert van der Horst wrote:
>> In article <o97do7$ru1$1@dont-email.me>,
>> Cecil Bayona  <cbayona@cbayona.com> wrote:
>>> Lately I've spent some time with C.H. Ting's eForth for the esp8266 and
>>> I been trying to improve it since I can see that some obvious
>>> improvements are possible but I'm having problems with the tools used.
>>> As an initial step I modified the code by making indenting, and function
>>> separations be consistent, I also been adding comments as to what is
>>> going on, I like the software I work with to be well documented
>>>

>
> To tell the truth a good part of the reason to work on this is that I
> have not used C in years and want to get used to it again, I did some
> major projects in C but that was a few years ago.
>

Well, I initially thought that the Arduino platform was using a 
simplified version of C++ but several books and web sites kept saying it 
was C. After starting the process of converting the software I find it 
is C++ since it has the usage of classes and objects. The Arduino 
software has a lot of things hidden from the user in the name of making 
things simpler including header, and libraries that are not mentioned 
but are loaded anyway.

So tomorrow I will need to do some reading on C++ classes so I can 
create the missing items, dummies at first so I can find the other 
errors, then go back and flesh them out. Oh what fun.

Actually it would be easier to convert the code to plain C without 
classes and it would be more portable at that. All of this is for the 
sake of having a version of eForth on C++ or C so it can be migrated 
somewhat easier. What a can of worms I have on my hands.

-- 
Cecil - k5nwa

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

#55521

Cecil Bayona <cbayona@cbayona.com> writes:
> So tomorrow I will need to do some reading on C++ classes so I can
> create the missing items, dummies at first so I can find the other
> errors, then go back and flesh them out. Oh what fun.

C++ is a lot different (better) now than it was 20 years ago.  C++11 was
a huge change.  You might read a recent book that covers it.  I like
"Effective Modern C++" by Scott Mayer.  This might also be of interest:

https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

> Actually it would be easier to convert the code to plain C without
> classes and it would be more portable at that. All of this is for the
> sake of having a version of eForth on C++ or C so it can be migrated
> somewhat easier. What a can of worms I have on my hands.

Why is eForth in C so interesting or important?  I thought the great
thing about eForth was that it was written in Forth, and in a very
simple way.  But it's not all that useful a Forth.  If you want a Forth
in C, why not one of the many others that are out there?

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

#55522

On 3/7/2017 10:39 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> So tomorrow I will need to do some reading on C++ classes so I can
>> create the missing items, dummies at first so I can find the other
>> errors, then go back and flesh them out. Oh what fun.
>
> C++ is a lot different (better) now than it was 20 years ago.  C++11 was
> a huge change.  You might read a recent book that covers it.  I like
> "Effective Modern C++" by Scott Mayer.  This might also be of interest:
>
> https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines
>
>> Actually it would be easier to convert the code to plain C without
>> classes and it would be more portable at that. All of this is for the
>> sake of having a version of eForth on C++ or C so it can be migrated
>> somewhat easier. What a can of worms I have on my hands.
>
> Why is eForth in C so interesting or important?  I thought the great
> thing about eForth was that it was written in Forth, and in a very
> simple way.  But it's not all that useful a Forth.  If you want a Forth
> in C, why not one of the many others that are out there?
>
I had on my list for future purchase Bjarne Stroustrup "The C++ 
Programming Language" but a bizarre thing is that the eBook is twice as 
expensive as the Hardbound copy at $58, I bought it just now, I need a 
reference of the language so I bit the bullet.

Bjarne Stroustrup Programming: Principles and Practice Using C++ $46 
again the eBook is more expensive, maybe later I will buy it, maybe not.

I added  "Effective Modern C++" by Scott Mayer to my list, that one is 
about $25 for the eBook, I just went and bought it, and if it's no good 
I'll send that Mafia after you.

Rather than convert to C I will take the opportunity to become more 
familiar with C++ which I put off long enough.

I'm glad to hear that C++ is a lot better now, after all It's been a lot 
of years since I looked at it and said thanks but no.

Why this eForth in C++, in reality only the Forth VM is written in C++ 
the rest is in Forth so it's very portable, easy to understand, easy to 
make changes to so it's an exercise for me to get my feet wet with C++, 
and have a Forth that can be easily compiled for almost any CPU I want. 
While learning C++ I wanted a simple piece of software to work with and 
this fits the bill.

After I master this copy and have it the way I want it then I will look 
at other more complicated versions. For now it's a learning project.

-- 
Cecil - k5nwa

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

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

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

csiph-web