Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #27952 > unrolled thread
| Started by | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| First post | 2014-01-19 13:15 -0500 |
| Last post | 2014-01-23 11:51 -0800 |
| Articles | 5 on this page of 65 — 15 participants |
Back to article view | Back to comp.lang.forth
quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 13:15 -0500
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 20:07 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-19 21:45 +0000
Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-19 22:02 +0100
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 17:24 -0600
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 14:54 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 22:37 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 18:01 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 00:27 -0500
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 20:54 -1000
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 21:19 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 12:07 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 11:37 -0500
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-21 17:41 +0000
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 08:30 -1000
Re: quick review of <BUILDS and CREATE history oh2aun@gmail.com - 2014-01-21 11:17 -0800
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 09:44 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 15:18 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 12:07 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 22:04 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 19:21 -1000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:38 +0000
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 08:50 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-23 17:17 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-23 13:46 -1000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:07 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:18 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 20:18 +0100
Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-25 20:44 +0100
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 21:41 +0100
Re: quick review of <BUILDS and CREATE history "Alex McDonald" <blog@rivadpm.com> - 2014-01-25 22:47 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:54 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 16:49 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:40 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-27 23:00 +0100
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-27 19:43 -0500
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-28 09:25 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-28 19:45 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:32 +0000
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:20 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:28 +0000
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 13:51 -0600
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:34 +0000
Re: quick review of <BUILDS and CREATE history Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-24 08:11 +0100
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:28 -0800
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 05:00 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:32 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:48 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 13:14 -1000
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:16 -0800
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-23 12:13 -0500
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:32 +0000
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-20 04:14 -0800
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-20 06:31 -0600
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 08:04 -1000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-21 14:09 +0000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 17:44 -0800
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 18:24 -0800
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-23 14:00 +0000
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:06 -0800
Re: quick review of <BUILDS and CREATE history Paul Rubin <no.email@nospam.invalid> - 2014-01-23 11:33 -0800
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:42 -0800
Re: quick review of <BUILDS and CREATE history Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 11:51 -0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-23 14:00 +0000 |
| Message-ID | <52e12096$0$24921$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #28013 |
In article <a9515cf3-de28-462c-a9a1-18056d65b655@googlegroups.com>, <trebor.english@gmail.com> wrote: <SNIP> >memory still has the same stuff in it. It is rewriteable. You can >write new data over the old data as much as you want. > <SNIP> > >Now, fast forward 30 years, flash memory is plentiful and can't be >rewritten. It is not possible to put the byte count in the flash then Now fast forward another three years. Write-as-often-as-you-like, read-for-eternity-even-after-power-off is back. <SNIP> What were you saying? 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]
| From | trebor.english@gmail.com |
|---|---|
| Date | 2014-01-23 11:06 -0800 |
| Message-ID | <e50d648b-a7a3-4c58-8029-4f1b838c125b@googlegroups.com> |
| In reply to | #28026 |
On Thursday, January 23, 2014 9:00:54 AM UTC-5, Albert van der Horst wrote: > <trebor.english@gmail.com> wrote: > > <SNIP> > > >memory still has the same stuff in it. It is rewriteable. You can > >write new data over the old data as much as you want. > > <SNIP> > > >Now, fast forward 30 years, flash memory is plentiful and can't be > >rewritten. It is not possible to put the byte count in the flash then > > > > Now fast forward another three years. > > Write-as-often-as-you-like, read-for-eternity-even-after-power-off is back. > > > > <SNIP> > > > > What were you saying? > > > > Groetjes Albert > > -- > The flash memory can be written many times. The problem is that it is only possible to change 1 bits to zero bits. To change zero bits back to ones requires erasing a page. In the case of the Atmel AVR ATmega644, for example, pages of 128 words get erased. If you want to put a header in a dictionary and the first byte contains the byte count you can't write the byte count and then later set the hex 80 bit for smudge. That would require changing a zero to a one. To do that requires erasing 128 words. Similarly you can't later write the 40 hex bit to make a colon definition immediate. When CREATE creates the header those bits are both zero. That is fine for constants, variables, user variables but unfortunate for colon definitions. The CFA is a similar problem. There was a suggestion to copy to ram, erase, copy back to flash. That will be slow and require a ram area of 128 words, 256 bytes, just to accommodate writing wrong stuff to flash then fixing it later. With core memory or 4116 16k ram chips there was no penalty. Now with different technology there is a penalty for writing wrong stuff. If the writing gets delayed until the correct information is known then the penalty for fixing it up later can be avoided. The only impetus to do it the traditional way is that the standard requires CREATE. There are standard parts of CREATE that have a substantial cost if flash is used. Since the technology is different now there is reason to consider doing things differently to accommodate the technology.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-23 11:33 -0800 |
| Message-ID | <7xbnz2xzmb.fsf@ruckus.brouhaha.com> |
| In reply to | #28038 |
trebor.english@gmail.com writes: > There was a suggestion to copy to ram, erase, copy back to flash. > That will be slow and require a ram area of 128 words, 256 bytes, Another possibility is write to an unused page (or more than one) in flash and keep moving a pointer forward (use a ram cell to hold the pointer). Copy back from this temp flash once the DOES> is handled. Once the temp data in flash has filled a whole page, erase it.
[toc] | [prev] | [next] | [standalone]
| From | trebor.english@gmail.com |
|---|---|
| Date | 2014-01-23 11:42 -0800 |
| Message-ID | <51c7bfce-7175-4e81-bcb7-3aa40a90ef39@googlegroups.com> |
| In reply to | #28039 |
On Thursday, January 23, 2014 2:33:00 PM UTC-5, Paul Rubin wrote: > trebor.english@gmail.com writes: > > > There was a suggestion to copy to ram, erase, copy back to flash. > > That will be slow and require a ram area of 128 words, 256 bytes, > > Another possibility is write to an unused page (or more than one) in > flash and keep moving a pointer forward (use a ram cell to hold the > pointer). Copy back from this temp flash once the DOES> is handled. > Once the temp data in flash has filled a whole page, erase it. Granted, you can start a definition in one place, copy for the smudge bit, copy for the immediate bit, copy for the DOES> CFA or copy for the CFA for ;CODE. All this copying is so that you can lay down wrong stuff in the dictionary and come back to fix it later. My point is still that it is possible to put stuff into flash when you have the necessary information rather than write junk because it is traditional and easy to write junk before you know what needs to be there. With flash it is harder to clean up the junk. It is not hard to only write good stuff, just not traditional. Copying to another piece of flash is fine now since the endurance is 100,000 erase cycles. When it was only 1000 cycles copying to other flash pages was not such a good idea. Yes it can be done. Slowly, with lots more code.
[toc] | [prev] | [next] | [standalone]
| From | Mikael Nordman <oh2aun@gmail.com> |
|---|---|
| Date | 2014-01-23 11:51 -0800 |
| Message-ID | <fd1c2ce0-235e-48a9-9b21-0c508e66ff95@googlegroups.com> |
| In reply to | #28038 |
On Thursday, January 23, 2014 9:06:10 PM UTC+2, trebor....@gmail.com wrote: > The flash memory can be written many times. The problem is that it is only possible to change 1 bits to zero bits. To change zero bits back to ones requires erasing a page. In the case of the Atmel AVR ATmega644, for example, pages of 128 words get erased. If you want to put a header in a dictionary and the first byte contains the byte count you can't write the byte count and then later set the hex 80 bit for smudge. That would require changing a zero to a one. To do that requires erasing 128 words. Similarly you can't later write the 40 hex bit to make a colon definition immediate. When CREATE creates the header those bits are both zero. That is fine for constants, variables, user variables but unfortunate for colon definitions. The CFA is a similar problem. > > There was a suggestion to copy to ram, erase, copy back to flash. That will be slow and require a ram area of 128 words, 256 bytes, just to accommodate writing wrong stuff to flash then fixing it later. With core memory or 4116 16k ram chips there was no penalty. Now with different technology there is a penalty for writing wrong stuff. If the writing gets delayed until the correct information is known then the penalty for fixing it up later can be avoided. > This is exactly how FlashForth works, except that it keeps the current flash page in ram until a word is fully defined. It work really well. Mikael http://flashforth.sourceforge.net
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web