Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58497 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-02 15:27 +0100 |
| Last post | 2017-05-04 10:07 -0700 |
| Articles | 17 on this page of 177 — 26 participants |
Back to article view | Back to comp.lang.forth
Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-05-07 17:38 -0700 |
| Message-ID | <87vapcb2sc.fsf@nightsong.com> |
| In reply to | #58798 |
Bernd Paysan <bernd@net2o.de> writes: > but I think most NAND flashes still are 512 bytes NAND flash pages are much larger than that, like 64k or larger, depending on the part. Good SSD's have less write amplification (= ratio of page size to block size) and will juggle blocks around behind the scenes, but devices like SD cards are of little help for that. There are file systems like F2FS (Linux) and an embedded one that I'm forgetting, that are designed to work well with flash. The Forth BLOCK words aren't quite the right thing, as Anton says. But, there are other media like FRAM that are a lot better. It will be interesting to see if Optane makes it down to the small embedded level.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 13:40 +0000 |
| Message-ID | <2017May8.154041@mips.complang.tuwien.ac.at> |
| In reply to | #58800 |
Paul Rubin <no.email@nospam.invalid> writes:
>But, there are other
>media like FRAM that are a lot better. It will be interesting to see if
>Optane makes it down to the small embedded level.
AFAIK both FRAM and phase-change memory (as used by Optane) allow
small read and write granularity, i.e., they can be used like RAM. No
blocks interface needed.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-08 13:25 +0000 |
| Message-ID | <2017May8.152530@mips.complang.tuwien.ac.at> |
| In reply to | #58798 |
Bernd Paysan <bernd@net2o.de> writes:
>Am Sun, 07 May 2017 10:39:24 +0100 schrieb Alex:
>
>> On 5/7/2017 09:58, Andrew Haley wrote:
>>> What's wrong with BLOCK, though? It sounds perfect for flash.
>>
>> It's too simplistic as a low level interface, and would require a lot of
>> support either on-chip or in the I/O stack. NAND flash isn't really a
>> random access block or byte addressable medium.
>
>BLOCK was originally for disks, and it copied the contents of the
>referenced block into RAM. So it matches NAND flash access style
>perfectly (maybe with the exception of how big the NAND flash granularity
>is - but I think most NAND flashes still are 512 bytes, while large hard
>disks nowadays have 4k sectors).
As reported by Alex, there are flash devices with 16MB erase
granularity and 16KB read/write granularity. 1KB blocks are
definitely not perfect, and if we want to just adjust the block size
while keeping the basic interface, the obvious solution would be to go
for 16MB blocks on these devices. 16KB blocks may be more to our
liking, but because we need to erase the surrounding 16MB to write the
16KB block, would require some kind of flash translation layer.
In other words:
1KB blocks: everything but "perfect".
16KB blocks: slightly closer.
16MB blocks: An ok fit to the blocks interface, but does not make good
use of the possibility of 16KB read/write blocks. And 16MB blocks may
be a bad fit for the application.
As for hard disks, shingled magnetic recording also gives us large
granularity (several MB) when writing.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-08 16:25 +0200 |
| Message-ID | <8637cfe884.fsf@molnjunk.nocrew.org> |
| In reply to | #58829 |
Anton Ertl wrote: > As reported by Alex, there are flash devices with 16MB erase > granularity and 16KB read/write granularity. 1KB blocks are > definitely not perfect, and if we want to just adjust the block size > while keeping the basic interface, the obvious solution would be to go > for 16MB blocks on these devices. This certainly changes the meaning of "a screenful of code". :-) Assuming, of course, that a screen is the size of a block.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-07 10:51 +0000 |
| Subject | Flash (was: Recognizers discussion) |
| Message-ID | <2017May7.125137@mips.complang.tuwien.ac.at> |
| In reply to | #58760 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> I am not an expert on microcontrollers, but my impression is that
>> these days they have flash memory that behaves like RAM when reading,
>> but can be written only with a certain granularity (which may,
>> however, be larger than the 1024 characters of a standard block).
>> Maybe microcontroller users can fill in how they use this.
...
>What's wrong with BLOCK, though? It sounds perfect for flash.
See above. To expand on that:
NOR flash as present in many microcontrollers can be read like ROM, no
need to copy it into RAM for that, as blocks would do. Writes are
divided into erase and write cycles, and the erase often has a block
size larger than 1KB, even on NOR flash. E.g., from
<https://wiki.openwrt.org/doc/techref/flash>:
|typical block sizes are e.g. 64KB for a 4MB NOR flash, 64KB for a
|256MB NAND flash, 128KB for a 512MB NAND flash
NAND flash requires copying into RAM, so it's closer to the block
wordset model, but again, the block sizes don't fit the standard block
wordset, and there is the difference between erase and write cycles.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-07 08:06 -0500 |
| Subject | Re: Flash |
| Message-ID | <b9SdnYhKwvB4hpLEnZ2dnUU7-aPNnZ2d@supernews.com> |
| In reply to | #58768 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> I am not an expert on microcontrollers, but my impression is that >>> these days they have flash memory that behaves like RAM when reading, >>> but can be written only with a certain granularity (which may, >>> however, be larger than the 1024 characters of a standard block). >>> Maybe microcontroller users can fill in how they use this. > ... >>What's wrong with BLOCK, though? It sounds perfect for flash. > > See above. To expand on that: > > NOR flash as present in many microcontrollers can be read like ROM, no > need to copy it into RAM for that, as blocks would do. Writes are > divided into erase and write cycles, and the erase often has a block > size larger than 1KB, even on NOR flash. E.g., from > <https://wiki.openwrt.org/doc/techref/flash>: > > |typical block sizes are e.g. 64KB for a 4MB NOR flash, 64KB for a > |256MB NAND flash, 128KB for a 512MB NAND flash OK, but I don't understand what the block size has to do with anything. If a physical block is larger than 1k, BLOCK will still work just fine, so I'm left scratching my head about what the problem might be. I take your point that copying into RAM is wasteful, though, both of time and RAM. It might require double buffering, which again is a pain (or might be impossible) on embedded controllers with limited RAM. > NAND flash requires copying into RAM, so it's closer to the block > wordset model, but again, the block sizes don't fit the standard block > wordset, and there is the difference between erase and write cycles. SSDs use NAND flash AFAIK, and work well with block-based file systems. But somehow NAND flash won't work with BLOCK. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-07 13:57 +0000 |
| Subject | Re: Flash |
| Message-ID | <2017May7.155729@mips.complang.tuwien.ac.at> |
| In reply to | #58770 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> |typical block sizes are e.g. 64KB for a 4MB NOR flash, 64KB for a
>> |256MB NAND flash, 128KB for a 512MB NAND flash
>
>OK, but I don't understand what the block size has to do with
>anything. If a physical block is larger than 1k, BLOCK will still
>work just fine, so I'm left scratching my head about what the problem
>might be.
With a 64KB erase block size, writing one 1KB block means reading the
64KB into RAM, copying the 1KB, into the buffer, erasing the 64KB on
the flash device, and then writing the 64KB back. That's not what I
consider "perfect".
>SSDs use NAND flash AFAIK, and work well with block-based file
>systems. But somehow NAND flash won't work with BLOCK.
SSDs have extra hardware plus a lot of firmware smarts (called flash
translation layer) so that they behave acceptably in the usual case
for the usual file systems. I.e., they put a lot of effort into
simulating a disk drive that was the inspiration for blocks. You
don't want to put that kind of effort into the implementation of
blocks on an embedded controller with access to raw flash. Instead,
the Forth way is to use an interface that is appropriate for flash.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-05-07 16:46 +0200 |
| Subject | Re: Flash |
| Message-ID | <86k25sencr.fsf@molnjunk.nocrew.org> |
| In reply to | #58772 |
Anton Ertl wrote: > With a 64KB erase block size, writing one 1KB block means reading the > 64KB into RAM, copying the 1KB, into the buffer, erasing the 64KB on > the flash device, and then writing the 64KB back. If the choices are that, or writing a flash-based file system, I'd rather chose blocks. A third option would be someting non-standard, of course.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-07 16:31 +0100 |
| Subject | Re: Flash |
| Message-ID | <oeneeu$akg$1@dont-email.me> |
| In reply to | #58772 |
On 5/7/2017 14:57, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> |typical block sizes are e.g. 64KB for a 4MB NOR flash, 64KB for a >>> |256MB NAND flash, 128KB for a 512MB NAND flash NOR flash is a dying market. Nobody wants the stuff, & it's too expensive to fab at high densities. >> >> OK, but I don't understand what the block size has to do with >> anything. If a physical block is larger than 1k, BLOCK will still >> work just fine, so I'm left scratching my head about what the problem >> might be. > > With a 64KB erase block size, writing one 1KB block means reading the > 64KB into RAM, copying the 1KB, into the buffer, erasing the 64KB on > the flash device, and then writing the 64KB back. That's not what I > consider "perfect". 3D NAND parts now have page sizes of 16KB and blocksizes of 16MB; that's without the ECC bits, which are another 2KB/2MB or so on top. Erase is hugely expensive in terms of latency on these parts. > >> SSDs use NAND flash AFAIK, and work well with block-based file >> systems. But somehow NAND flash won't work with BLOCK. > > SSDs have extra hardware plus a lot of firmware smarts (called flash > translation layer) so that they behave acceptably in the usual case > for the usual file systems. I.e., they put a lot of effort into > simulating a disk drive that was the inspiration for blocks. You > don't want to put that kind of effort into the implementation of > blocks on an embedded controller with access to raw flash. Instead, > the Forth way is to use an interface that is appropriate for flash. Most of them, when faced with a page update that requires a block erase, move the block to be erased to another free block on the device, and then do the update without support from the requester. This can be a major cause of jitter. Some simply remap the block and the pages within it in internal block assignment tables. But when you run out of fresh blocks, something has to be erased, and that's when the performance problems start. A lot implement block based log structured file systems internally. The industry went with disk based Flash because it was an easily implemented technology. But the limitations are very clear (bandwidth is one; 160MB/s on sequential writes is considered excellent, but it's where we are with the humble spinning disks). -- Alex
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-07 17:16 +0000 |
| Subject | Re: Flash |
| Message-ID | <2017May7.191617@mips.complang.tuwien.ac.at> |
| In reply to | #58775 |
Alex <alex@rivadpm.com> writes:
>On 5/7/2017 14:57, Anton Ertl wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> |typical block sizes are e.g. 64KB for a 4MB NOR flash, 64KB for a
>>>> |256MB NAND flash, 128KB for a 512MB NAND flash
>
>NOR flash is a dying market. Nobody wants the stuff, & it's too
>expensive to fab at high densities.
That may be the case for SSDs, but if you want to execute code
directly from flash, as in many microcontrollers, you use NOR flash:
<https://electronics.stackexchange.com/questions/168875/is-the-rom-of-an-mcu-nand-flash>
>3D NAND parts now have page sizes of 16KB and blocksizes of 16MB
I assume that means 16KB read and write granularity, and 16MB erase
granularity? If not, what does it mean?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-07 19:18 +0100 |
| Subject | Re: Flash |
| Message-ID | <oeno7r$dsh$1@dont-email.me> |
| In reply to | #58779 |
On 5/7/2017 18:16, Anton Ertl wrote: >> 3D NAND parts now have page sizes of 16KB and blocksizes of 16MB > I assume that means 16KB read and write granularity, and 16MB erase > granularity? If not, what does it mean? Yes, that exactly. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-05-07 21:45 +0200 |
| Subject | Re: Flash |
| Message-ID | <oentgq$s4e$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #58779 |
In article <2017May7.191617@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Alex <alex@rivadpm.com> writes: >>On 5/7/2017 14:57, Anton Ertl wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> |typical block sizes are e.g. 64KB for a 4MB NOR flash, 64KB for a >>>>> |256MB NAND flash, 128KB for a 512MB NAND flash >> >>NOR flash is a dying market. Nobody wants the stuff, & it's too >>expensive to fab at high densities. > >That may be the case for SSDs, but if you want to execute code >directly from flash, as in many microcontrollers, you use NOR flash: > ><https://electronics.stackexchange.com/questions/168875/is-the-rom-of-an-mcu-nand-flash> > >>3D NAND parts now have page sizes of 16KB and blocksizes of 16MB > >I assume that means 16KB read and write granularity, and 16MB erase >granularity? If not, what does it mean? The msp430 has 256 byte granularity for the program memory. So it is practical to replace only part of the program. The noforth boys manage do support incremental development quite well. > >- anton 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 | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-07 12:54 -0700 |
| Subject | Re: Flash |
| Message-ID | <7a7e97f5-1c35-494c-bf5a-bf9b53b742ca@googlegroups.com> |
| In reply to | #58786 |
> The msp430 has 256 byte granularity for the program memory. > So it is practical to replace only part of the program. The AVR8 parts have even smaller page sizes, and, what's even nicer, an otherwise hidden ram area of that size to keep a flash page during erase cycles. That way, an emulation of byte level write access can be easily done. Works well for amforth for more than 10 years using the same controller chip for development. Matthias
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-07 19:33 +0100 |
| Subject | Re: Flash |
| Message-ID | <oenp3l$gs9$1@dont-email.me> |
| In reply to | #58775 |
On 5/7/2017 16:31, Alex wrote: > NOR flash is a dying market. Nobody wants the stuff, & it's too > expensive to fab at high densities. I'm not right here. I've done a bit of research, and it appears that, although demand has fallen of precipitously in prior years, there may be future demand; for the support of AMOLED displays. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2017-05-07 08:50 -0700 |
| Subject | Re: Flash |
| Message-ID | <5ff594b1-dd92-4e5d-a20a-7b20146d738c@googlegroups.com> |
| In reply to | #58772 |
> With a 64KB erase block size, writing one 1KB block means reading the > 64KB into RAM, copying the 1KB, into the buffer, erasing the 64KB on > the flash device, and then writing the 64KB back. That's not what I > consider "perfect". Who says you should do that? In fact nobody's doing that. For one thing you risk the entire 64K in a power off event. There's also the flash wearing level to consider... > SSDs have extra hardware plus a lot of firmware smarts (called flash > translation layer) so that they behave acceptably in the usual case > for the usual file systems. I.e., they put a lot of effort into > simulating a disk drive that was the inspiration for blocks. You > don't want to put that kind of effort into the implementation of > blocks on an embedded controller with access to raw flash. Instead, > the Forth way is to use an interface that is appropriate for flash. I don't understand what you mean. Dealing with raw flash is not very simple but also not very complicated. Implementing fixed 1K blocks addressed by numbers (in the forth way) is much more simpler than implementing a file system. But you should implement something don't you?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-07 17:21 +0000 |
| Subject | Re: Flash |
| Message-ID | <2017May7.192133@mips.complang.tuwien.ac.at> |
| In reply to | #58776 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> With a 64KB erase block size, writing one 1KB block means reading the
>> 64KB into RAM, copying the 1KB, into the buffer, erasing the 64KB on
>> the flash device, and then writing the 64KB back. That's not what I
>> consider "perfect".
>
>Who says you should do that? In fact nobody's doing that.
It's the simplest approach.
>For one thing
>you risk the entire 64K in a power off event. There's also the flash
>wearing level to consider...
Good reasons to go for a more complicated approach. Which supports my
point: the blocks wordset is not perfect for flash.
>> Instead,
>> the Forth way is to use an interface that is appropriate for flash.
>
>I don't understand what you mean. Dealing with raw flash is not very
>simple but also not very complicated. Implementing fixed 1K blocks
>addressed by numbers (in the forth way) is much more simpler than
>implementing a file system. But you should implement something don't you?
Sure. AFAIK the users of microcontrollers with NOR flash use flash
not for blocks, but for storing the write-once parts of the
dictionary. But someone with first-hand experience is in a better
position to provide information.
Likewise for NAND flash. Does it play a role in Forth systems? If
so, what is it used for and how is it accessed? Once we know that, we
may find a better solution than just saying: "Blocks are great,
because they were great for floppies, and they are still simpler than
a file system".
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Matthias Trute <matthias.trute@gmail.com> |
|---|---|
| Date | 2017-05-04 10:07 -0700 |
| Message-ID | <0e24be2b-468a-4453-b636-827dae27f210@googlegroups.com> |
| In reply to | #58669 |
Am Donnerstag, 4. Mai 2017 17:37:26 UTC+2 schrieb rickman: > On 5/2/2017 10:27 AM, Alex wrote: > > On 5/2/2017 09:49, Andrew Haley wrote: > > > > I've started a new thread for clarity. I'm answering one at a time as my > > time permits. > > > >> The proposal allows recognizers to precede dictionary searches, so > >> that even if a word would have been found it might not be executed > >> because a recognizer got in there first. This will not help > >> debugging; it is not a good thing. > > > > > > But Forth has never insisted on protecting the programmer from not good > > things; qv the "ain't Forth weird!" example of 1 CONSTANT 0 . And a > > system with recognizers should, since backward compatibility is > > essential, be able to act in entirely the same way as a classical > > interpreter. The only difference will be the inability to add > > recognizers, simple, literal or otherwise, in a standard way. > > Backward compatibility with applications is important, backward > compatibility with previous versions of the standard is not. Otherwise > changes would never be made. That's a pretty abstract statement. With recognizers no backward compatibility gets broken, every word in the current and past standards remains the same. btw: Andras Pahi pointed me to the following link http://ficl.sourceforge.net/parsesteps.html, which is pretty close to recognizers and a really old invention. Does ficl count as a remote Forth cousin? > How often does any app you are aware of redefine literal values as > words? Old forthers may remember 1, 0, -1 and some more numbers. As word they took only one cell in the dictionary instead of 2 for the usual "literal number" sequence. True only on optimizer-less ITC systems, probably. Matthias
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.forth
csiph-web