Hi,
> Let's pick an easy example at random. This is currently abs ( n -- u )
> implementation:
I expected something different, changing ABS is easy. Not worth a discussion.
> I was suggesting a group hacking effort where Matthias marks which words
> to rewrite.
For me code size is more importan
Hello Erich,
Erich Waelde writes:
> Hi Enoch,
>
> On 12/19/2013 03:25 PM, Enoch wrote:
>> Hello AmForth-ers:
>>
>> I don't think that people look for speed when considering any Forth --
>> modern optimizing C compilers will do better.
>>
>> Nevertheless, I think that we need to rid AmForth ker
Hi Enoch,
On 12/19/2013 03:25 PM, Enoch wrote:
> Hello AmForth-ers:
>
> I don't think that people look for speed when considering any Forth --
> modern optimizing C compilers will do better.
>
> Nevertheless, I think that we need to rid AmForth kernel ASAP of VM
> instruction calls (those pesky
Hello AmForth-ers:
I don't think that people look for speed when considering any Forth --
modern optimizing C compilers will do better.
Nevertheless, I think that we need to rid AmForth kernel ASAP of VM
instruction calls (those pesky XT_'s) and leave them for compiled code
output only. Let's sta
Hello,
> Has there been any thought about optimizer?
A lot. And a lot of discussions with people who
know a lot more than I do in this specific area
of wisdom. The final judgment is as it is: for
an ITC forth there are only very few possibilities.
One is a statistical analysis to find code seque
I haven't done real hard measurements but the systems are different. I have
been able to fit a program on atmega328 with Amforth which was designed for
AtMega128 and it consumed between 40 to 60 kB flash.
Also in some libraries there are so long delay() functions that MCU is just
counting while
