Menu
▾
▴
amforth-devel
|
From: Enoch <ix...@ho...> - 2013-06-06 19:37:37
|
Hello AmForth-ers,
Can somebody give me good reasons why we should not convert words/*.asm
implementations (as much as possible) from VM assembly to AVR
assembly.
For example:
; ( a-addr1 -- a-addr2 )
; Arithmetics
; add the size of an address-unit to a-addr1
VE_CELLPLUS:
.dw $ff05
.db "cell+",0
.dw VE_HEAD
.set VE_HEAD = VE_CELLPLUS
Current implementation:
=======================
XT_CELLPLUS:
.dw DO_COLON
PFA_CELLPLUS:
.if CELLSIZE == 2 ;
.dw XT_1PLUS
.dw XT_1PLUS
.else
.dw XT_DOLITERAL
.dw CELLSIZE
.dw XT_PLUS
.endif
.dw XT_EXIT
Suggested implementation:
=========================
XT_CELLPLUS: .dw pc + 1
adiw tosl, CELLSIZE
jmp_ DO_NEXT
There are two good reasons to prefer the AVR implementation:
1. Speed (10x faster?)
2. Ease of debugging through the Studio.
Comments? [flames :-)]
Thanks, Enoch.
|
|
From: Rafael G. <ast...@ya...> - 2013-06-07 08:11:18
|
One of the criteria that you should use is that the pure assembly implementation should not exceed in size to the VM assembly implementation +10% (let's give a margin, ok?) Speed, yes but not sacrifying compactness Rafael ________________________________ De: Enoch <ix...@ho...> Para: amf...@li... Enviado: Jueves 6 de junio de 2013 21:37 Asunto: [Amforth] Waking up a dormant forum :-) Hello AmForth-ers, Can somebody give me good reasons why we should not convert words/*.asm implementations (as much as possible) from VM assembly to AVR assembly. For example: ; ( a-addr1 -- a-addr2 ) ; Arithmetics ; add the size of an address-unit to a-addr1 VE_CELLPLUS: .dw $ff05 .db "cell+",0 .dw VE_HEAD .set VE_HEAD = VE_CELLPLUS Current implementation: ======================= XT_CELLPLUS: .dw DO_COLON PFA_CELLPLUS: .if CELLSIZE == 2 ; .dw XT_1PLUS .dw XT_1PLUS .else .dw XT_DOLITERAL .dw CELLSIZE .dw XT_PLUS .endif .dw XT_EXIT Suggested implementation: ========================= XT_CELLPLUS: .dw pc + 1 adiw tosl, CELLSIZE jmp_ DO_NEXT There are two good reasons to prefer the AVR implementation: 1. Speed (10x faster?) 2. Ease of debugging through the Studio. Comments? [flames :-)] Thanks, Enoch. ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amf...@li... https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Michael K. <mi-...@t-...> - 2013-06-07 08:44:39
|
Hi. > ..but not sacrifying compactness Here is what you can do with NO vm kernel word at all: http://mecrisp.sourceforge.net/ ..standalone native code Forth for MSP430 microcontroller chips... ..It fits tightly into 9kb of Flash and runs with 512 Bytes of Ram... By the way, its free. Use whatever routine you like, a great pit. A good job Matthias did there - no not Trute, is Koch this time. :-) Good luck! Michael Am 07.06.2013 um 10:11 schrieb Rafael Gonzalez: > One of the criteria that you should use is that the pure assembly > implementation should not exceed > in size to the VM assembly implementation +10% (let's give a > margin, ok?) > Speed, yes but not sacrifying compactness > Rafael > > > ________________________________ > De: Enoch <ix...@ho...> > Para: amf...@li... > Enviado: Jueves 6 de junio de 2013 21:37 > Asunto: [Amforth] Waking up a dormant forum :-) > > > Hello AmForth-ers, > > Can somebody give me good reasons why we should not convert words/ > *.asm > implementations (as much as possible) from VM assembly to AVR > assembly. > > For example: > > ; ( a-addr1 -- a-addr2 ) > ; Arithmetics > ; add the size of an address-unit to a-addr1 > VE_CELLPLUS: > .dw $ff05 > .db "cell+",0 > .dw VE_HEAD > .set VE_HEAD = VE_CELLPLUS > > Current implementation: > ======================= > > XT_CELLPLUS: > .dw DO_COLON > PFA_CELLPLUS: > .if CELLSIZE == 2 ; > .dw XT_1PLUS > .dw XT_1PLUS > .else > .dw XT_DOLITERAL > .dw CELLSIZE > .dw XT_PLUS > .endif > .dw XT_EXIT > > > Suggested implementation: > ========================= > > XT_CELLPLUS: .dw pc + 1 > adiw tosl, CELLSIZE > jmp_ DO_NEXT > > > There are two good reasons to prefer the AVR implementation: > > 1. Speed (10x faster?) > 2. Ease of debugging through the Studio. > > Comments? [flames :-)] > > Thanks, Enoch. > > > > > > ---------------------------------------------------------------------- > -------- > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ---------------------------------------------------------------------- > -------- > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Matthias T. <mt...@we...> - 2013-06-07 14:50:05
|
Hi Enoch, > Can somebody give me good reasons why we should not convert > words/*.asm implementations (as much as possible) from VM assembly > to AVR assembly. I should do so, perhaps ;) > > For example: A well chosen one, indeed. > There are two good reasons to prefer the AVR implementation: > > 1. Speed (10x faster?) Speed is always an argument. Size too. And maintainability. And the indisputable fact that forth makes more fun than assembler. > 2. Ease of debugging through the Studio. I used the AVR Studio years ago when I started with the inner core of amforth. Since it worked (around version 0.1) I never used it again. > Comments? [flames :-)] You example patch is welcome, it is indeed an improvement in both size and speed. Thanks for it; the current code is an artefact from the times I thought an 3 byte cell size is worth doing. In general I'd like to see as much as possible code written in forth. Most of the "VM" code solves the chicken-and-egg problem, I should remove what's not needed for that purpose and put it into the lib/ directory tree. But I already hear the screams, that this stripped system will be too difficult to use. I found it interesting that quite a lot of forth code examples need less space than the respective assembly code. Trivialities excluded. Matthias |
|
From: Enoch <ix...@ho...> - 2013-06-08 01:18:47
|
Hello Matthias, Ok, I think that we can sum up the manifesto concerning standard words implementation as follows: * Prefer AVR assembly language if the speed improvement is significant while code bloating is insignificant. * VM assembly language is ugly (.dw FETCH vs. @) thus, whenever possible, define new words in Forth and leave VM coding for the compiler to do. Now let's roll up our sleeves :-) Regards, Enoch. Matthias Trute <mt...@we...> writes: > Hi Enoch, > >> Can somebody give me good reasons why we should not convert >> words/*.asm implementations (as much as possible) from VM assembly >> to AVR assembly. > > I should do so, perhaps ;) > >> >> For example: > > A well chosen one, indeed. > >> There are two good reasons to prefer the AVR implementation: >> >> 1. Speed (10x faster?) > > Speed is always an argument. Size too. And maintainability. > And the indisputable fact that forth makes more fun than > assembler. > >> 2. Ease of debugging through the Studio. > > I used the AVR Studio years ago when I started > with the inner core of amforth. Since it worked > (around version 0.1) I never used it again. > >> Comments? [flames :-)] > > You example patch is welcome, it is indeed an > improvement in both size and speed. Thanks for it; > the current code is an artefact from the times > I thought an 3 byte cell size is worth doing. > > In general I'd like to see as much as possible > code written in forth. Most of the "VM" code > solves the chicken-and-egg problem, I should > remove what's not needed for that purpose and > put it into the lib/ directory tree. But I > already hear the screams, that this stripped > system will be too difficult to use. > > I found it interesting that quite a lot of > forth code examples need less space than the > respective assembly code. Trivialities excluded. > > Matthias > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j |
|
From: Enoch <ix...@ho...> - 2013-06-08 00:38:13
|
"Michael Kalus" <mi-...@t-...> writes: > Hi. > >> ..but not sacrifying compactness > > Here is what you can do with NO vm kernel word at all: > http://mecrisp.sourceforge.net/ > ..standalone native code Forth for MSP430 microcontroller chips... > ..It fits tightly into 9kb of Flash and runs with 512 Bytes of Ram... > > By the way, its free. Use whatever routine you like, a great pit. > A good job Matthias did there - no not Trute, is Koch this time. :-) > > Good luck! > Michael > Hello Michael, Not again what's the best 8 bit micro :-) I chose the AVR a couple of years ago for its better open source C support. Now we are here at AmForth to make its Forth variant the best around too! And our Matthias is doing great job and he has demonstratd being open to criticism too! We still have to convince him though what's the correct stack order .s ;-) Cheers, Enoch. > > > > > > > > > Am 07.06.2013 um 10:11 schrieb Rafael Gonzalez: > >> One of the criteria that you should use is that the pure assembly >> implementation should not exceed >> in size to the VM assembly implementation +10% (let's give a >> margin, ok?) >> Speed, yes but not sacrifying compactness >> Rafael >> >> >> ________________________________ >> De: Enoch <ix...@ho...> >> Para: amf...@li... >> Enviado: Jueves 6 de junio de 2013 21:37 >> Asunto: [Amforth] Waking up a dormant forum :-) >> >> >> Hello AmForth-ers, >> >> Can somebody give me good reasons why we should not convert words/ >> *.asm >> implementations (as much as possible) from VM assembly to AVR >> assembly. >> >> For example: >> >> ; ( a-addr1 -- a-addr2 ) >> ; Arithmetics >> ; add the size of an address-unit to a-addr1 >> VE_CELLPLUS: >> .dw $ff05 >> .db "cell+",0 >> .dw VE_HEAD >> .set VE_HEAD = VE_CELLPLUS >> >> Current implementation: >> ======================= >> >> XT_CELLPLUS: >> .dw DO_COLON >> PFA_CELLPLUS: >> .if CELLSIZE == 2 ; >> .dw XT_1PLUS >> .dw XT_1PLUS >> .else >> .dw XT_DOLITERAL >> .dw CELLSIZE >> .dw XT_PLUS >> .endif >> .dw XT_EXIT >> >> >> Suggested implementation: >> ========================= >> >> XT_CELLPLUS: .dw pc + 1 >> adiw tosl, CELLSIZE >> jmp_ DO_NEXT >> >> >> There are two good reasons to prefer the AVR implementation: >> >> 1. Speed (10x faster?) >> 2. Ease of debugging through the Studio. >> >> Comments? [flames :-)] >> >> Thanks, Enoch. >> >> >> >> >> >> ---------------------------------------------------------------------- >> -------- >> How ServiceNow helps IT people transform IT departments: >> 1. A cloud service to automate IT design, transition and operations >> 2. Dashboards that offer high-level views of enterprise services >> 3. A single system of record for all IT processes >> http://p.sf.net/sfu/servicenow-d2d-j >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> ---------------------------------------------------------------------- >> -------- >> How ServiceNow helps IT people transform IT departments: >> 1. A cloud service to automate IT design, transition and operations >> 2. Dashboards that offer high-level views of enterprise services >> 3. A single system of record for all IT processes >> http://p.sf.net/sfu/servicenow-d2d-j >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j |
|
From: Michael K. <mi-...@t-...> - 2013-06-08 01:04:07
|
Hi. Am 08.06.2013 um 02:37 schrieb Enoch: > "Michael Kalus" <mi-...@t-...> > writes: > >> Hi. >> >>> ..but not sacrifying compactness >> >> Here is what you can do with NO vm kernel word at all: >> http://mecrisp.sourceforge.net/ >> ..standalone native code Forth for MSP430 microcontroller chips... >> ..It fits tightly into 9kb of Flash and runs with 512 Bytes of Ram... >> >> By the way, its free. Use whatever routine you like, a great pit. >> A good job Matthias did there - no not Trute, is Koch this time. :-) >> >> Good luck! >> Michael >> > > Hello Michael, > > Not again what's the best 8 bit micro :-) I chose the AVR a couple of > years ago for its better open source C support. Now we are here at > AmForth to make its Forth variant the best around too! Mecrisp is just an example that it can be done, and it could be done on AVR as well I guess. > And our Matthias is doing great job and he has demonstratd being > open to > criticism too! Thats true, without doubt. > We still have to convince him though what's the correct > stack order .s ;-) Which is without doubt too. ;-) Michael > > Cheers, Enoch. > >> >> >> >> >> >> >> >> >> Am 07.06.2013 um 10:11 schrieb Rafael Gonzalez: >> >>> One of the criteria that you should use is that the pure assembly >>> implementation should not exceed >>> in size to the VM assembly implementation +10% (let's give a >>> margin, ok?) >>> Speed, yes but not sacrifying compactness >>> Rafael >>> >>> >>> ________________________________ >>> De: Enoch <ix...@ho...> >>> Para: amf...@li... >>> Enviado: Jueves 6 de junio de 2013 21:37 >>> Asunto: [Amforth] Waking up a dormant forum :-) >>> >>> >>> Hello AmForth-ers, >>> >>> Can somebody give me good reasons why we should not convert words/ >>> *.asm >>> implementations (as much as possible) from VM assembly to AVR >>> assembly. >>> >>> For example: >>> >>> ; ( a-addr1 -- a-addr2 ) >>> ; Arithmetics >>> ; add the size of an address-unit to a-addr1 >>> VE_CELLPLUS: >>> .dw $ff05 >>> .db "cell+",0 >>> .dw VE_HEAD >>> .set VE_HEAD = VE_CELLPLUS >>> >>> Current implementation: >>> ======================= >>> >>> XT_CELLPLUS: >>> .dw DO_COLON >>> PFA_CELLPLUS: >>> .if CELLSIZE == 2 ; >>> .dw XT_1PLUS >>> .dw XT_1PLUS >>> .else >>> .dw XT_DOLITERAL >>> .dw CELLSIZE >>> .dw XT_PLUS >>> .endif >>> .dw XT_EXIT >>> >>> >>> Suggested implementation: >>> ========================= >>> >>> XT_CELLPLUS: .dw pc + 1 >>> adiw tosl, CELLSIZE >>> jmp_ DO_NEXT >>> >>> >>> There are two good reasons to prefer the AVR implementation: >>> >>> 1. Speed (10x faster?) >>> 2. Ease of debugging through the Studio. >>> >>> Comments? [flames :-)] >>> >>> Thanks, Enoch. >>> >>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> -------- >>> How ServiceNow helps IT people transform IT departments: >>> 1. A cloud service to automate IT design, transition and operations >>> 2. Dashboards that offer high-level views of enterprise services >>> 3. A single system of record for all IT processes >>> http://p.sf.net/sfu/servicenow-d2d-j >>> _______________________________________________ >>> Amforth-devel mailing list for http://amforth.sf.net/ >>> Amf...@li... >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >>> -------------------------------------------------------------------- >>> -- >>> -------- >>> How ServiceNow helps IT people transform IT departments: >>> 1. A cloud service to automate IT design, transition and operations >>> 2. Dashboards that offer high-level views of enterprise services >>> 3. A single system of record for all IT processes >>> http://p.sf.net/sfu/servicenow-d2d-j >>> _______________________________________________ >>> Amforth-devel mailing list for http://amforth.sf.net/ >>> Amf...@li... >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> >> >> --------------------------------------------------------------------- >> --------- >> How ServiceNow helps IT people transform IT departments: >> 1. A cloud service to automate IT design, transition and operations >> 2. Dashboards that offer high-level views of enterprise services >> 3. A single system of record for all IT processes >> http://p.sf.net/sfu/servicenow-d2d-j > > > ---------------------------------------------------------------------- > -------- > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
|
From: Erich W. <ew....@na...> - 2013-06-10 10:07:07
|
Hello, answering late ... On 06/06/2013 09:37 PM, Enoch wrote: > Hello AmForth-ers, > > Can somebody give me good reasons why we should not convert words/*.asm > implementations (as much as possible) from VM assembly to AVR > assembly. Isn't this about the usual tradeoff between "portability" and "speed/size"? A Forth system can be implemented with as little as 7 words written in assembly. This stuff is simpler to port to the next controller, or at least less work. So the next question is: is this "keep the assembly part as small as possible" credo important for amforth? Probably not, because it is designed to run on "atmega" exclusively. The "atXmega" stuff has been largely abandoned, if I remember correctly. So, no, apart maybe from readability of the code there is not much to say against using more assembly. AVRStudio is in my case not an argument at all, because I do not use it. Cheers, Erich |
|
From: Matthias T. <mt...@we...> - 2013-06-10 17:35:27
|
Hi, > A Forth system can be implemented with as little as 7 words written in 3 words, according to Frank Seargant. > assembly. This stuff is simpler to port to the next controller, or at least > less work. So the next question is: is this "keep the assembly part as > small as possible" credo important for amforth? Probably not, because it > is designed to run on "atmega" exclusively. The "atXmega" stuff has been > largely abandoned, if I remember correctly. atxmega frustate me everytime I re-start with them. The tool chain on linux is not yet ready for them. IMHO. But I do not give up, yet ;) And who knows, maybe I use the code as inspiration for something completely other controllers? I've got a few ARM's right on my desk... > So, no, apart maybe from readability of the code there is not much to say > against using more assembly. I'd agree if someone writes an optimizing cross-compiler from forth code to assembler code. Simply converting from one syntax notation to another is already done with the G4 tool. Matthias |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X