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 1 of 3  [1] 2 3  Next page →

#55332 — esp8266 eForth and it's development software

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.

Dr. Ting chose to use the Arduino Software Platform to compile the 
eForth VM but the Arduino software is somewhat lacking in tools, for 
example I have not been able to find a way to see the C code and the 
instructions it generates so I can come up with a more efficient version 
of code sequences.

An alternative is to load the esp8266 development tools (GCC) since they 
do have a way of displaying the C code along with the generated code. 
The Arduino code provided is easily converted back to C code so that is 
no a problem.

I rather stay with the Arduino platform if possible, so do you know of 
any way to see the generated code with the C statements? I'm not very 
familiar with the Arduino software so there might be a way.

Thanks
-- 
Cecil - k5nwa

[toc] | [next] | [standalone]

#55333

On 03/01/2017 03:18 PM, Cecil Bayona wrote:
> I rather stay with the Arduino platform if possible, so do you know of
> any way to see the generated code with the C statements? I'm not very
> familiar with the Arduino software so there might be a way.

I have no idea how the ESP8266 is handled but the package of tools for
the Teensy 3.6 (I am working on an eForth for that in assembler)
includes the gcc tools. I just had to poke around until I found where it
was at.

The Arduino IDE builds the project in a temporary directory including a
.elf file. So it is easy to run objdump on the elf file and see the
code. But the IDE deletes all of that when it shuts down so you will
need to copy it elsewhere if you want to keep it around.

Of course once you find the gcc tools you can use gas.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

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

#55339

On 3/1/2017 3:29 PM, David Schultz wrote:
> On 03/01/2017 03:18 PM, Cecil Bayona wrote:
>> I rather stay with the Arduino platform if possible, so do you know of
>> any way to see the generated code with the C statements? I'm not very
>> familiar with the Arduino software so there might be a way.
>
> I have no idea how the ESP8266 is handled but the package of tools for
> the Teensy 3.6 (I am working on an eForth for that in assembler)
> includes the gcc tools. I just had to poke around until I found where it
> was at.
>
> The Arduino IDE builds the project in a temporary directory including a
> .elf file. So it is easy to run objdump on the elf file and see the
> code. But the IDE deletes all of that when it shuts down so you will
> need to copy it elsewhere if you want to keep it around.
>
> Of course once you find the gcc tools you can use gas.
>
OK, I compiled the project, then while leaving the Arduino Software open 
I started nosing around and I found some stuff. the esp8266 extension 
include the esp8266 GCC compilers and a bunch of tools, they did not 
place these tools in the Program folder but in a data folder so I keep 
looking.

I normally use Windows 10 so I'm not familiar with the GCC software but 
so far I don't see where the compiled program work files are stored, 
I've looked in several places but have not found it yet.

Does the.elf file contain the name of the project to cut down the this 
when searching for a .elf file? Gas? Pray tell what is that.

I finally found the file, after objdump with the "-d -S" OPTIONS what a 
mess you end up with, it displays 10s of thousands of lines, every 
library in the Universe, even code that is disabled from compiling shows 
executable code, what a mess.

I'm going to have to figure something else out.

-- 
Cecil - k5nwa

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

#55343

On 03/01/2017 05:16 PM, Cecil Bayona wrote:
> Does the.elf file contain the name of the project to cut down the this
> when searching for a .elf file? Gas? Pray tell what is that.
> 

I believe that the .elf file has the same name as the .ino file.

gas = GNU assembler.


-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

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

#55345

On 3/1/2017 5:51 PM, David Schultz wrote:
> On 03/01/2017 05:16 PM, Cecil Bayona wrote:
>> Does the.elf file contain the name of the project to cut down the this
>> when searching for a .elf file? Gas? Pray tell what is that.
>>
>
> I believe that the .elf file has the same name as the .ino file.
>
> gas = GNU assembler.
>
>
Thanks

Looking at the code produced by the Arduino Software/GCC it is horribly 
inefficient code, of course part of it could be if the CPU has a lousy 
instruction set won't know for a while.

-- 
Cecil - k5nwa

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

#55346

Cecil Bayona <cbayona@cbayona.com> writes:
> Looking at the code produced by the Arduino Software/GCC it is
> horribly inefficient code, of course part of it could be if the CPU
> has a lousy instruction set won't know for a while.

The cpu instruction set looked ok in the quick look I gave it.  Maybe
the GCC port is not very good.

The follow-on ESP32 processor is a lot more powerful so maybe upgrading
to that is more interesting than tweaking the 8266 version.

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

#55348

On 3/1/2017 6:53 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> Looking at the code produced by the Arduino Software/GCC it is
>> horribly inefficient code, of course part of it could be if the CPU
>> has a lousy instruction set won't know for a while.
>
> The cpu instruction set looked ok in the quick look I gave it.  Maybe
> the GCC port is not very good.
>
> The follow-on ESP32 processor is a lot more powerful so maybe upgrading
> to that is more interesting than tweaking the 8266 version.
>
I did a quick scan of the instruction set myself and it did appear 
useless, must be the GCC port it's brand new and the code generated 
looks poor.

The esp32 basic improvement is that it has two cores one dedicated to 
the WiFi so one does not have to "yield" to the WiFi code, it also has 
added hardware such as Bluetooth, but the Arduino interface was not 
ready as of earlier this week, and even if it was it's bound to be buggy 
and generate bad code, I still would have the same issues I have now.

Another angle at it is to use a different CPU for now that has a decent 
Arduino port and use it to tweak the software, then as the esp8266 port 
improves so will the running code, I have Arduino for MSP430, and PIC32 
and both have been around for a while.

Another angle is to adapt the software to C/C++, I have Rowley 
Associates C/C++ for ARM and work with that. I'll have to think about 
that, working with poor tools won't help much. Rowley has the advantage 
of awesome IDE, and excellent debugging tools, I have a Seeger JTAG 
interface to debug software with. I also have quite a few ARM boards 
with tons of FLASH and RAM. The more I think on it, this might be the 
way to go with tools that give one full control.

-- 
Cecil - k5nwa

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

#55349

Cecil Bayona <cbayona@cbayona.com> writes:
> I did a quick scan of the instruction set myself and it did appear
> useless, must be the GCC port it's brand new and the code generated
> looks poor.

You mean the 8266 instruction set is bad?  Maybe you're right, I didn't
look closely, it just seemed like a distantly MIPS-related 32 bit
vanilla cpu.

> Another angle at it is to use a different CPU for now that has a
> decent Arduino port and use it to tweak the software

You mean Eforth?  There's tons of other Forths available for the ARM
etc.; is Eforth of particular interest?

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

#55350

On 3/1/2017 7:56 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> I did a quick scan of the instruction set myself and it did appear
>> useless, must be the GCC port it's brand new and the code generated
>> looks poor.
>
> You mean the 8266 instruction set is bad?  Maybe you're right, I didn't
> look closely, it just seemed like a distantly MIPS-related 32 bit
> vanilla cpu.
>
>> Another angle at it is to use a different CPU for now that has a
>> decent Arduino port and use it to tweak the software
>
> You mean Eforth?  There's tons of other Forths available for the ARM
> etc.; is Eforth of particular interest?
>
Amazing what one word left out and how it changes things, I meant not 
useless.

I'm looking at this because for any CPU that has a C compiler which is 
just about any CPU in existence one could generate a quickie eForth 
compiler for it, but to be useful the C code needs to be better than 
what is at present, mainly eliminate the division, and selective use of 
macros to generate better code. Also it would help to have an optimizing 
compiler that is available for many CPUs so most likely GCC would be the 
route for now.

To work on it and tweak it well it is to my benefit to use decent tools 
to speed up the process, that why I am currently favoring the use of 
Rowleys C/C++ compiler (based on GCC) and tools to tweak the compiler as 
good as it can get, I already own a copy, it's easy to use, and has 
decent tools including excellent debugging capabilities to figure where 
things are going wrong.

For ARM and MSP430 I already own MPE Professional compilers but for 
everything else it would be nice to have a readily available Forth.

-- 
Cecil - k5nwa

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

#55351

Cecil Bayona <cbayona@cbayona.com> writes:
> I'm looking at this because for any CPU that has a C compiler which is
> just about any CPU in existence one could generate a quickie eForth
> compiler for it, but to be useful the C code needs to be better than
> what is at present, mainly eliminate the division,

Do you have an assembly code sample showing this division?

Could you fix the C code to not use a division?  What does the C code
look like now?

> To work on it and tweak it well it is to my benefit to use decent
> tools to speed up the process, that why I am currently favoring the
> use of Rowleys C/C++ compiler (based on GCC)

I didn't know that, I thought the Rowley compiler was independent.

> For ARM and MSP430 I already own MPE Professional compilers but for
> everything else it would be nice to have a readily available Forth.

eForth is a really cool self-hosted implementation that's lots of fun to
read, but it's minimalistic and you might want to use some alternative.

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

#55352

On 3/1/2017 8:57 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> I'm looking at this because for any CPU that has a C compiler which is
>> just about any CPU in existence one could generate a quickie eForth
>> compiler for it, but to be useful the C code needs to be better than
>> what is at present, mainly eliminate the division,
>
> Do you have an assembly code sample showing this division?
>
> Could you fix the C code to not use a division?  What does the C code
> look like now?
>
>> To work on it and tweak it well it is to my benefit to use decent
>> tools to speed up the process, that why I am currently favoring the
>> use of Rowleys C/C++ compiler (based on GCC)
>
> I didn't know that, I thought the Rowley compiler was independent.
>
>> For ARM and MSP430 I already own MPE Professional compilers but for
>> everything else it would be nice to have a readily available Forth.
>
> eForth is a really cool self-hosted implementation that's lots of fun to
> read, but it's minimalistic and you might want to use some alternative.
>
Rowley uses both their own compiler and GCC, but the interface and many 
of the tools is theirs.

It has code all over the place that will do things like;

IP = data(IP / sizeof(w)); and other similar code where the index into 
an array is calculated using division, the generated code is huge like 
it's not optimizing at all.

IP = instruction pointer in bytes
w is a temporary working register a long integer or 4 bytes but it could 
be two in some cases
data is an long array containing the dictionary/code

Faster would be using >> to shift the value 2 places instead of divide 
since it's a power of two.
Even faster would be to use a different variable that is the offset in 
long words so no math is required at all.

-- 
Cecil - k5nwa

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

#55353

On 03/01/2017 09:17 PM, Cecil Bayona wrote:
> Faster would be using >> to shift the value 2 places instead of divide
> since it's a power of two.
> Even faster would be to use a different variable that is the offset in
> long words so no math is required at all.
> 

I remember finding a file buried in the arduino installation mess for
the Teensy that had all of the options passed to gcc. Including a "-Os".

There it is!
/usr/share/arduino-1.6.12/hardware/teensy/avr/boards.txt

But I see that there is a file of that name for the ESP32 but it doesn't
contain compile options. That seems to be in platform.txt.

So poke around as something might turn up.

-- 
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

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

#55355

On 3/1/2017 9:38 PM, David Schultz wrote:
> On 03/01/2017 09:17 PM, Cecil Bayona wrote:
>> Faster would be using >> to shift the value 2 places instead of divide
>> since it's a power of two.
>> Even faster would be to use a different variable that is the offset in
>> long words so no math is required at all.
>>
>
> I remember finding a file buried in the arduino installation mess for
> the Teensy that had all of the options passed to gcc. Including a "-Os".
>
> There it is!
> /usr/share/arduino-1.6.12/hardware/teensy/avr/boards.txt
>
> But I see that there is a file of that name for the ESP32 but it doesn't
> contain compile options. That seems to be in platform.txt.
>
> So poke around as something might turn up.
>
Thanks I will look tomorrow, I need to get up early for a dreaded 
Dentist appointment, I just found a sliver of bone coming out of my gum 
where he had pulled a tooth, sharp as a needle.

-- 
Cecil - k5nwa

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

#55354

Cecil Bayona <cbayona@cbayona.com> writes:
> IP = data(IP / sizeof(w));

You've inspected the asm code and there's really a division there?

Why not just change it to a shift?

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

#55357

On 3/1/2017 9:40 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> IP = data(IP / sizeof(w));
>
> You've inspected the asm code and there's really a division there?
>
> Why not just change it to a shift?
>
In some cases it uses shift in a few cases it uses divide, below is an 
example where it uses shift, it's pretty hard to find anything as the 
code is all mixed up with libraries in between routines;

void cellsl(void) {
   top /= sizeof(w);
40201c60:	fffc31        	l32r	a3, 40201c50 <_Z22__run_user_rf_pre_initv+0x4>
40201c63:	fffe51        	l32r	a5, 40201c5c 
<_Z22__run_user_rf_pre_initv+0x10>
40201c66:	0328      	l32i.n	a2, a3, 0
40201c68:	424b      	addi.n	a4, a2, 4
40201c6a:	0349      	s32i.n	a4, a3, 0
40201c6c:	fffa41        	l32r	a4, 40201c54 <_Z22__run_user_rf_pre_initv+0x8>
40201c6f:	0438      	l32i.n	a3, a4, 0
40201c71:	1239      	s32i.n	a3, a2, 4
40201c73:	fff921        	l32r	a2, 40201c58 <_Z22__run_user_rf_pre_initv+0xc>
40201c76:	0238      	l32i.n	a3, a2, 0
40201c78:	416230        	srli	a6, a3, 2
40201c7b:	a05650        	addx4	a5, a6, a5
40201c7e:	0558      	l32i.n	a5, a5, 0
40201c80:	334b      	addi.n	a3, a3, 4
40201c82:	0459      	s32i.n	a5, a4, 0
40201c84:	0239      	s32i.n	a3, a2, 0
40201c86:	f00d      	ret.n

An awful lot of code to store a number shifted right twice;

Looking at the code generated there is so much code to do something very 
simple that a divide would hardly be any worse, it has multiply and 
divide instructions built in.

  "top" is the cached top of the Data Stack so its replacing the top of 
the Data Stack with itself shifted right 2 places.

-- 
Cecil - k5nwa

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

#55336

Cecil Bayona <cbayona@cbayona.com> writes:
> 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, 

The minimal eforth primitives assume very little cpu capabilities,
e.g. not even multiplication.  So make sure there are primitives for all
that.

> for example the VM code that executes the next instruction, goes off
> on a eForth High Level subroutine, 

Make sure to mark that inline.  Maybe it's being taken care of though.

> pgets, 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.

The compiler might be optimizing that out.  It is good about stuff like
that.

Are you using the highest optimization level?  You might experiment with
some different ones.

I thought the underlying compiler for the 8266 Arduino setup was still
GCC, so can't you use GCC -S to look at the assembly code?

Is the speed of eForth on the 8266 a real practical issue for something,
or are you trying to make it faster on general principle?

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

#55340

On 3/1/2017 4:50 PM, Paul Rubin wrote:
> Cecil Bayona <cbayona@cbayona.com> writes:
>> 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,
>
> The minimal eforth primitives assume very little cpu capabilities,
> e.g. not even multiplication.  So make sure there are primitives for all
> that.
>

Address calculations are being done during the execution of every 
primitive that involves division.

>> for example the VM code that executes the next instruction, goes off
>> on a eForth High Level subroutine,
>
> Make sure to mark that inline.  Maybe it's being taken care of though.
>
>> pgets, 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.
>
> The compiler might be optimizing that out.  It is good about stuff like
> that.
>
> Are you using the highest optimization level?  You might experiment with
> some different ones.

This is Arduino none of that is available to the user, no options on 
optimizing or pretty much anything, it's made for people that know 
little about programming so all the options are gone, load a file into 
an edit window, then you tell it to install it on the target and that is 
about it. I might need to dump the Arduino software and just use GCC 
where I can have a lot of control.

>
> I thought the underlying compiler for the 8266 Arduino setup was still
> GCC, so can't you use GCC -S to look at the assembly code?

I might have to install GCC myself and modify the source to fit, then I 
can have control.
>
> Is the speed of eForth on the 8266 a real practical issue for something,
> or are you trying to make it faster on general principle?
>
General principle as there are some things in there that are way too 
inefficient to make it a practical system. The system is way too slow, 
and one see how things are being done very inefficiently so lots of room 
for improvement.

-- 
Cecil - k5nwa

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

#55341

Cecil Bayona <cbayona@cbayona.com> writes:
> General principle as there are some things in there that are way too
> inefficient to make it a practical system. The system is way too slow,
> and one see how things are being done very inefficiently so lots of
> room for improvement.

Is the 8266 C code online (non-pirated of course)?  I'd be interested in
taking a look.

You don't have a way to pass the -S flag to GCC in the Arduino setup?
That's the option for saving out the asm code.

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

#55344

On 3/1/2017 5:26 PM, Cecil Bayona wrote:
> On 3/1/2017 4:50 PM, Paul Rubin wrote:

> General principle as there are some things in there that are way too
> inefficient to make it a practical system. The system is way too slow,
> and one see how things are being done very inefficiently so lots of room
> for improvement.
>

Sorry I accidentally deleted your message.

The code is not public domain, it cost $25 but unlike some of his other 
versions this one is not well documented, still it's pretty simple and 
easy to understand.

1. Its a eForth Virtual Machine written in Arduino C which has some 
differences from real C but they are minor.

2. It has 67 primitives.

3. The rest of eForth is compiled with a eForth Meta-Compiler that is 
provided. It creates a memory image that is merged with the Arduino VM 
to create an image that is downloaded to the esp8266.

4. It is slowed because on every primitive executed an address 
calculation is performed involving division.

5. It is also slowed down because on every instruction fetch it executes 
"yield" yield is a routine that checks the wireless hardware for any 
traffic coming or going from the esp8266, thousands of CPU instructions 
are executed every time a Forth primitive is fetched, it's not necessary 
to call that code so often, it just waste a lot of CPU time.

On item #5 I will try something tomorrow to reduce that waste, on item 
#4 later in the weekend I need to do a test to see if the code can be 
easily speed-ed up.



-- 
Cecil - k5nwa

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

#55413

On 3/1/2017 3:18 PM, Cecil Bayona 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.
>
> Dr. Ting chose to use the Arduino Software Platform to compile the
> eForth VM but the Arduino software is somewhat lacking in tools, for
> example I have not been able to find a way to see the C code and the
> instructions it generates so I can come up with a more efficient version
> of code sequences.
>
> An alternative is to load the esp8266 development tools (GCC) since they
> do have a way of displaying the C code along with the generated code.
> The Arduino code provided is easily converted back to C code so that is
> no a problem.
>
> I rather stay with the Arduino platform if possible, so do you know of
> any way to see the generated code with the C statements? I'm not very
> familiar with the Arduino software so there might be a way.
>
> Thanks

Well I made up my mind what I want to do, I setup the Windows 7 i386 CPU 
with the latest Rowley C/C++ ARM Compiler and got it licensed so it's 
ready to go. That software has all the latest and greatest tools so I 
can see what the compiler is generating so I can optimize the eForth VM.

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.

After that I will try it out with the Rowley C/C++ MSP430 compiler, it 
should work right off the bat.

Much later another final test would be to install GCC or CLANG and tweak 
it so it works there, that software should be available in a multitude 
of CPUs.
-- 
Cecil - k5nwa

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web