Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #37726 > unrolled thread
| Started by | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| First post | 2015-03-29 12:43 +0000 |
| Last post | 2015-04-04 11:25 -0700 |
| Articles | 20 on this page of 80 — 21 participants |
Back to article view | Back to comp.lang.forth
Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-29 12:43 +0000
Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-29 06:15 -0700
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-29 15:11 +0000
Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-29 09:14 -0700
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-29 19:52 +0000
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-03-30 12:39 +0000
Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-30 09:09 -0700
Re: Importing from wordlists. stephen@mpeforth.com (Stephen Pelc) - 2015-03-30 16:42 +0000
Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-30 17:55 -0700
Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-04-02 05:41 -0700
Re: Importing from wordlists. "HAA" <someone@microsoft.com> - 2015-03-31 13:26 +1000
Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-30 19:54 -0700
Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-31 02:23 -0700
Re: Importing from wordlists. Lars Brinkhoff <lars.spam@nocrew.org> - 2015-03-31 12:02 +0200
Re: Importing from wordlists. Mark Wills <markwills1970@gmail.com> - 2015-03-31 07:41 -0700
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-03-31 16:36 +0100
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-03-31 16:52 +0000
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-03-31 18:33 +0100
Re: Importing from wordlists. JennyB <jennybrien@googlemail.com> - 2015-03-31 15:25 -0700
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 00:59 +0000
Re: Importing from wordlists. JennyB <jennybrien@googlemail.com> - 2015-04-01 08:05 -0700
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 15:25 +0000
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 15:58 +0000
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 15:57 +0100
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-03-31 23:58 +0100
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 02:00 +0200
Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-03-31 18:48 -0700
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-01 08:03 +0100
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 16:38 +0200
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 15:54 +0100
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 17:41 +0200
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-01 18:24 +0200
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-02 05:27 +0200
Re: Importing from wordlists. Coos Haak <chforth@hccnet.nl> - 2015-04-02 12:38 +0200
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-02 15:45 +0100
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-02 17:25 +0100
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-03 02:00 +0200
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-03 20:49 +0100
Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 11:08 -1000
Re: Importing from wordlists. Paul Rubin <no.email@nospam.invalid> - 2015-04-03 14:14 -0700
Re: Importing from wordlists. franck.bensusan@gmail.com - 2015-04-04 02:47 -0700
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-03 21:37 +0000
Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 14:05 -1000
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-04 05:14 +0200
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-04 14:07 +0000
Re: Importing from wordlists. Paul Rubin <no.email@nospam.invalid> - 2015-04-04 14:02 -0700
Re: Importing from wordlists. Melzzzzz <mel@zzzzz.com> - 2015-04-05 00:36 +0200
Re: Importing from wordlists. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 04:35 +0200
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-04 13:30 +0000
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-04 16:38 +0000
Re: Importing from wordlists. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 16:48 +0200
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 23:49 +0100
Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 14:09 -1000
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-04 20:30 +0100
Re: Importing from wordlists. hughaguilar96@gmail.com - 2015-04-04 13:29 -0700
Re: Importing from wordlists. Johan Kotlinski <kotlinski@gmail.com> - 2015-04-03 23:57 -0700
Re: Importing from wordlists. "Elizabeth D. Rather" <erather@forth.com> - 2015-04-03 21:35 -1000
Re: Importing from wordlists. krishna.myneni@ccreweb.org - 2015-04-04 10:00 -0700
Re: Importing from wordlists. Melzzzzz <mel@zzzzz.com> - 2015-04-04 19:08 +0200
Re: Importing from wordlists. Coos Haak <chforth@hccnet.nl> - 2015-04-02 22:45 +0200
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-03 02:08 +0200
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-02 20:59 +0100
Re: Importing from wordlists. Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-03 02:03 +0200
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-03 20:52 +0100
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-09 12:39 +0100
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 15:03 +0000
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 01:10 +0000
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-01 07:32 +0100
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 07:52 +0000
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 10:39 +0000
SYNONYM (wase: Importing from wordlists.) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 11:29 +0000
Re: SYNONYM (wase: Importing from wordlists.) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-01 15:08 +0000
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 15:49 +0100
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-01 17:12 +0000
Re: Importing from wordlists. "Alex McDonald" <blog@rivadpm.com> - 2015-04-01 18:45 +0100
Re: Importing from wordlists. Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-01 20:43 +0100
Re: Importing from wordlists. mhx@iae.nl (Marcel Hendrix) - 2015-04-04 09:53 +0200
Re: Importing from wordlists. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-04 14:20 +0000
Re: Importing from wordlists. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-04 17:10 +0000
Re: Importing from wordlists. mhx@iae.nl - 2015-04-04 11:25 -0700
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-04-04 02:47 -0700 |
| Message-ID | <0b043f18-a855-4341-9bdb-5f0aaf8c9c23@googlegroups.com> |
| In reply to | #37900 |
Le vendredi 3 avril 2015 23:14:03 UTC+2, Paul Rubin a écrit : > "Elizabeth D. Rather" <erather@forth.com> writes: > > I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived > > advantage of going 64-bit beyond generally "keeping up with fashion"? > > 64-bit programs usually run a lot faster. Wider data transfers, more > cpu registers (depending), etc. Plus the much larger address space, > which some memory hungry programs actually use. I'am currently working on an optimized Oforth version for 64bits architectures. Not finished yet but, for now, what I can say about it : Positive (imo) : ---------------- + Speed : 8 new registers available. ==> Can be used for local heap storage efficiently. + Speed : new instructions that work with qwords are available ==> All mathematics, floats, mem copy... are much faster. + Mem : Not limited to 2Go. But I have never had to do something that need this amount of memory. I think it could be a big advantage if you need to create large amount of threads, but this is not Oforth parallelism model. + Integers/pointers are now natively 64bits long. ==> Operations on them are as fast as 32bits. ==> You have access to native 64bits integers with no cost. Negative (imo) : ---------------- - Mem : All pointers are 64 bits ==> The data stack needs 2x memory, objects are x2. even if you don't need to reach the 2Go limit. - Mem : If token, each token is 64bits ==> Generated code with tokens is x2 ==> It is better to generate jit native code. - Mem : I still don't know why but executables files are much bigger. On Windows, Oforth 32 exe is a 140 kb standalone file (110 kb on linux). Oforth 64 is more than 250 kb size. This is not coming only from native code length... Have to check if the same happens on Linux. Perhap's gcc version or options or ... something else... Still have to find out why... and correct this. - Speed : More processor caches miss. - Speed : If no math operations, I'd guess 1.2 time faster for Oforth 64, no more... Even with 64bits specific optimizations. Speed gain is when you have intensive math operations / mem copy. - External function call is a pain (passing parameters, red zone, ...) and platform dependant (not the same registers are used to pass parameters). - If you want speed gain, you not only have to compile on 64 bits, you have to optimize for 64 bits (register use, use of operations on 64 bits memory, ...). Having the same code optimized for 32bits and 64 bits is difficult. I had to create a layer between interpreter source (assembler part) and compiler to generate optimized code according to target architecture before interpreter compilation. All in all, I must say that I'am a little deceived : not much speed gain (at least for now) and lots of memory lost if you don't need to reach 2Go... The main advantage is, imo, to allow many more threads creation (but this does not apply to oforth) and possibility to link to 64bits libraries, which are becoming the standard. Franck
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-03 21:37 +0000 |
| Message-ID | <2015Apr3.233709@mips.complang.tuwien.ac.at> |
| In reply to | #37899 |
"Elizabeth D. Rather" <erather@forth.com> writes:
> What is the perceived
>advantage of going 64-bit beyond generally "keeping up with fashion"?
You can make use of more address space.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-04-03 14:05 -1000 |
| Message-ID | <ePednWdB__8nt4LInZ2dnUU7-dudnZ2d@supernews.com> |
| In reply to | #37902 |
On 4/3/15 11:37 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> What is the perceived >> advantage of going 64-bit beyond generally "keeping up with fashion"? > > You can make use of more address space. I realize that's true in theory, but so far neither we nor our customers have pushed the boundaries of 32-bit address space, and we have had no demand for a 64-bit system to date. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-04 05:14 +0200 |
| Message-ID | <mfnkt7$6o6$1@dont-email.me> |
| In reply to | #37907 |
Elizabeth D. Rather wrote: > On 4/3/15 11:37 AM, Anton Ertl wrote: >> "Elizabeth D. Rather" <erather@forth.com> writes: >>> What is the perceived >>> advantage of going 64-bit beyond generally "keeping up with fashion"? >> >> You can make use of more address space. > > I realize that's true in theory, but so far neither we nor our customers > have pushed the boundaries of 32-bit address space, and we have had no > demand for a 64-bit system to date. We have about 2 decades of experience with 64 bits, first on MIPS64 and Alpha, and we do have that demand. Partially, because these platforms may have had only a 64 bit mode, and certainly because we can. The request for Windows 64 had been there for quite a while (probably from people who are used to the 64 bit Gforth on Linux), and Cygwin wasn't ready for that until a year or so ago. The crypto stuff I'm doing with net2o can be up to 4 times faster on 64 bits instead of 32 bits. That's because these modern crypto libraries are designed for 64 bit processors. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-04 14:07 +0000 |
| Message-ID | <2015Apr4.160753@mips.complang.tuwien.ac.at> |
| In reply to | #37907 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 4/3/15 11:37 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> What is the perceived
>>> advantage of going 64-bit beyond generally "keeping up with fashion"?
>>
>> You can make use of more address space.
>
>I realize that's true in theory, but so far neither we nor our customers
>have pushed the boundaries of 32-bit address space, and we have had no
>demand for a 64-bit system to date.
I have not needed it often, but there have been occasions where I used
more address space than available on 32-bit systems. I guess if it
was available to them, your customers would use it, too. But since it
isn't, they use some other way to achieve their goals.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-04-04 14:02 -0700 |
| Message-ID | <87lhi761zb.fsf@jester.gateway.sonic.net> |
| In reply to | #37907 |
"Elizabeth D. Rather" <erather@forth.com> writes: >> You can make use of more address space. > I realize that's true in theory, but so far neither we nor our > customers have pushed the boundaries of 32-bit address space, and we > have had no demand for a 64-bit system to date. I remember getting in a discussion with Anton here on clf about computing the billionth Hamming number, and he wrote some Forth code that did it with a clever algorithm that involved allocating a billion 64-bit cells (8GB). One could say that's not a real-world problem, but it's still a concrete example of a Forth program that someone considered interesting enough to write, that wouldn't have fit in a 32 bit system. As another issue, 64 bits give you much more safety from integer overflow. Maybe your program was written in the 1990's and did something with dialup modems. It might have been reasonable to use a 32-bit cell to hold the number of bytes transferred in a session. Run the same program now with broadband internet and you can overflow 32 bits in an hour or less. Programs deal with bigger numbers than they used to.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-04-05 00:36 +0200 |
| Message-ID | <20150405003638.16c61f2d@maxa-pc> |
| In reply to | #37944 |
On Sat, 04 Apr 2015 14:02:48 -0700 Paul Rubin <no.email@nospam.invalid> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > >> You can make use of more address space. > > I realize that's true in theory, but so far neither we nor our > > customers have pushed the boundaries of 32-bit address space, and we > > have had no demand for a 64-bit system to date. > > I remember getting in a discussion with Anton here on clf about > computing the billionth Hamming number, and he wrote some Forth code > that did it with a clever algorithm that involved allocating a billion > 64-bit cells (8GB). One could say that's not a real-world problem, > but it's still a concrete example of a Forth program that someone > considered interesting enough to write, that wouldn't have fit in a > 32 bit system. > > As another issue, 64 bits give you much more safety from integer > overflow. Maybe your program was written in the 1990's and did > something with dialup modems. It might have been reasonable to use a > 32-bit cell to hold the number of bytes transferred in a session. Run > the same program now with broadband internet and you can overflow 32 > bits in an hour or less. Programs deal with bigger numbers than they > used to. Heh my router has 32 bit CPU and traffic statistics uses 32 bit ints, and therefore is pretty useless ;)
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2015-04-04 04:35 +0200 |
| Message-ID | <co96hdFduiaU1@mid.individual.net> |
| In reply to | #37902 |
Anton Ertl schrieb: > "Elizabeth D. Rather" <erather@forth.com> writes: >> What is the perceived >> advantage of going 64-bit beyond generally "keeping up with fashion"? > > You can make use of more address space. ... provided that your system has the required amount of RAM. I suspect that many 64 bit applications do not care about memory requirements any more, and force my 8GB system into continuously swapping state. As soon as databases or other big data sets (files...) enter the scene, it's no problem to run out of physical memory by loading entire files into memory. In former days[tm] I could use WinWord 1.0 on Win3.1 on a 4MB notebook, even with big documents. But nowadays, who would care for such a sophisticated application and data segmentation, when the virtual address space is near unlimited? :-( DoDi
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-04 13:30 +0000 |
| Message-ID | <2015Apr4.153059@mips.complang.tuwien.ac.at> |
| In reply to | #37912 |
Hans-Peter Diettrich <DrDiettrich1@aol.com> writes:
>Anton Ertl schrieb:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> What is the perceived
>>> advantage of going 64-bit beyond generally "keeping up with fashion"?
>>
>> You can make use of more address space.
>
>... provided that your system has the required amount of RAM.
If you have more than 2-3GB RAM (process limits are different for
different OSs), then a 64-bit system allows you to make use of that in
one process, too. But more address space can be helpful even if you
do not have the RAM. E.g., it allows you to mmap disk files into the
address space if that is a convenient form of accessing the file in
your application. No need to worry about files that are too large for
the address space and no need to write alternative code for that case
(which would eliminate most of the benefits of using mmap).
>I suspect that many 64 bit applications do not care about memory
>requirements any more, and force my 8GB system into continuously
>swapping state.
In contrast, my 4GB system on which only 64-bit applications run
reports 3786000KB free (about 100MB of which are file buffers). I
guess you are running bloated software or are using lots of data.
>As soon as databases or other big data sets (files...)
>enter the scene, it's no problem to run out of physical memory by
>loading entire files into memory.
>
>In former days[tm] I could use WinWord 1.0 on Win3.1 on a 4MB notebook,
>even with big documents. But nowadays, who would care for such a
>sophisticated application and data segmentation, when the virtual
>address space is near unlimited? they regularly got crashes and:-(
I wonder what a big document is wrt WinWord 1.0. My doctoral thesis
takes 161KB as TeX source, 751KB as Postscript output or 488KB as PDF.
Either of these could be easily loaded in its entirety into RAM on a
4MB system; I heard about people who tried to do their thesis with
Word that Word crashed frequently and they lost work, with the cause
of the crash sometimes being in the saved file (so just restarting
Word did not necessarily help); so I have my doubts that Word could be
used for big (as in many pages) documents. Of course, it's possible
that it generated big files for small documents; in that case any
complicatiosn that it implemented to deal with these large files are
its own fault.
The way a file buffer is handled in an editor is certainly a
fundamental design decision. GNU Emacs loaded the whole file into RAM
early on (long before there was a 64-bit port), which increases the
footprint, but simplifies the implementation.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-04 16:38 +0000 |
| Message-ID | <5520137e$0$21331$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #37927 |
In article <2015Apr4.153059@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: <SNIP> > >The way a file buffer is handled in an editor is certainly a >fundamental design decision. GNU Emacs loaded the whole file into RAM >early on (long before there was a 64-bit port), which increases the >footprint, but simplifies the implementation. In 1983 I was on the MANIP team, working on Unix for the first time partly PDP partly VAX. We decided that neither vi nor emacs were any good, so Edwin wrote Edwin's editor, the one I'm using right now. I advised him to look forward to VAX, not backwards to PDP, and just load the file in memory. We never looked back. Now I routinely inspect Gbyte test files from euler projects with it. It has lazy loading. You see the start of the file immediately, and if you just quit the Gbytes are never read into memory. (The MSDOS port suffered, you couldn't get above a couple of 100 kbyte with it, but at least you had multiple file editing on MSDOS). It is extensible. I had an extension once that interpreted a ctags file and jumped directly to the correct place in the source. (Lost it, those things are not really important if you have your projects under control.) > >- anton -- 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 | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2015-04-04 16:48 +0200 |
| Message-ID | <cobod8F300bU2@mid.individual.net> |
| In reply to | #37927 |
Anton Ertl schrieb: > The way a file buffer is handled in an editor is certainly a > fundamental design decision. GNU Emacs loaded the whole file into RAM > early on (long before there was a 64-bit port), which increases the > footprint, but simplifies the implementation. EMACS = Eight Megabytes Almost Continuously Swapping ;-) You are right, every application should be aware of systems with little RAM, or of big files exceeding physical RAM. This has been true for 16 and 32 bit address space, and still is true for 64 bit address space. DoDi
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-03 23:49 +0100 |
| Message-ID | <mfn5c9$1j7$1@dont-email.me> |
| In reply to | #37899 |
on 03/04/2015 22:07:58, "Elizabeth D. Rather" wrote: > On 4/3/15 9:49 AM, Gerry Jackson wrote: >> On 03/04/2015 01:00, Bernd Paysan wrote: >>> Question: How many people need a 32 bit Gforth on Windows? Is there any >>> demand for that or is the 64 bit Gforth just fine? AMD64 has been >>> introduced more than 10 years ago, and Windows XP has reached EOL; if you >>> want to be vintage, you can as well use the old Gforth 0.7 executable >>> ;-). >> >> I still use 32 bit Windows 7, I've never felt the need to move to 64 >> bits and probably won't until I get a new computer. >> > > I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived > advantage of going 64-bit beyond generally "keeping up with fashion"? > > Cheers, > Elizabeth > "All programming is an exercise in caching."; Terje Mathisen. Way back when I was a lad, 16 bit programs had overlays and all sorts of segmentation trickery to get round a much smaller limit, and 32 bits looked like luxury. Now, not so much. Addressing beyond the 4GB limit (and some OSes limit 32bit apps to less) of memory as a cache makes programming much easier.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-04-03 14:09 -1000 |
| Message-ID | <9-idnVrSKvQgtoLInZ2dnUU7-audnZ2d@supernews.com> |
| In reply to | #37904 |
On 4/3/15 12:49 PM, Alex McDonald wrote: > on 03/04/2015 22:07:58, "Elizabeth D. Rather" wrote: >> On 4/3/15 9:49 AM, Gerry Jackson wrote: >>> On 03/04/2015 01:00, Bernd Paysan wrote: >>>> Question: How many people need a 32 bit Gforth on Windows? Is there any >>>> demand for that or is the 64 bit Gforth just fine? AMD64 has been >>>> introduced more than 10 years ago, and Windows XP has reached EOL; if you >>>> want to be vintage, you can as well use the old Gforth 0.7 executable >>>> ;-). >>> >>> I still use 32 bit Windows 7, I've never felt the need to move to 64 >>> bits and probably won't until I get a new computer. >>> >> >> I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived >> advantage of going 64-bit beyond generally "keeping up with fashion"? >> >> Cheers, >> Elizabeth >> > > "All programming is an exercise in caching."; Terje Mathisen. Way back > when I was a lad, 16 bit programs had overlays and all sorts of > segmentation trickery to get round a much smaller limit, and 32 bits > looked like luxury. Now, not so much. Addressing beyond the 4GB limit > (and some OSes limit 32bit apps to less) of memory as a cache makes > programming much easier. > Yes, but it makes programs run much slower. Back in the 16-bit era we were able to out-perform a number of programs because Forth applications were so much smaller than programs written other ways, and a very major factor was the lack of necessity for caching. So far, since going to 32-bit systems in the 80's, we haven't seen a need for caching in 32-bit address space. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-04 20:30 +0100 |
| Message-ID | <mfpe3b$32r$1@dont-email.me> |
| In reply to | #37908 |
on 04/04/2015 01:09:33, "Elizabeth D. Rather" wrote: > On 4/3/15 12:49 PM, Alex McDonald wrote: >> on 03/04/2015 22:07:58, "Elizabeth D. Rather" wrote: >>> On 4/3/15 9:49 AM, Gerry Jackson wrote: >>>> On 03/04/2015 01:00, Bernd Paysan wrote: >>>>> Question: How many people need a 32 bit Gforth on Windows? Is there any >>>>> demand for that or is the 64 bit Gforth just fine? AMD64 has been >>>>> introduced more than 10 years ago, and Windows XP has reached EOL; if you >>>>> want to be vintage, you can as well use the old Gforth 0.7 executable >>>>> ;-). >>>> >>>> I still use 32 bit Windows 7, I've never felt the need to move to 64 >>>> bits and probably won't until I get a new computer. >>>> >>> >>> I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived >>> advantage of going 64-bit beyond generally "keeping up with fashion"? >>> >>> Cheers, >>> Elizabeth >>> >> >> "All programming is an exercise in caching."; Terje Mathisen. Way back >> when I was a lad, 16 bit programs had overlays and all sorts of >> segmentation trickery to get round a much smaller limit, and 32 bits >> looked like luxury. Now, not so much. Addressing beyond the 4GB limit >> (and some OSes limit 32bit apps to less) of memory as a cache makes >> programming much easier. >> > > Yes, but it makes programs run much slower. Back in the 16-bit era we > were able to out-perform a number of programs because Forth > applications were so much smaller than programs written other ways, > and a very major factor was the lack of necessity for caching. So far, > since going to 32-bit systems in the 80's, we haven't seen a need for > caching in 32-bit address space. > > Cheers, > Elizabeth > Well, there are two sides to this. 64 bit processors and lots of memory (TB range) let you run large numbers of virtual machines. I'm running a 64 bit 32GB laptop and it can support 5 or so VMs without breaking into too much of a sweat. I use them for running my company's products that support parallel NFS (pNFS). Gobs of memory are essential for high performance SAN and NAS systems; block, file base (NFS, SMB), and object based systems work so much better when data is not on disk but in main memory. When you're supporting storage with multi PB of disk at the back end, these huge main memory caches are essential. 32 bit we don't support, and haven't for a long time.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-04 13:29 -0700 |
| Message-ID | <d104a08c-e8ac-49f8-98d7-9274f17a08c9@googlegroups.com> |
| In reply to | #37908 |
On Friday, April 3, 2015 at 5:09:35 PM UTC-7, Elizabeth D. Rather wrote: > On 4/3/15 12:49 PM, Alex McDonald wrote: > > on 03/04/2015 22:07:58, "Elizabeth D. Rather" wrote: > >> On 4/3/15 9:49 AM, Gerry Jackson wrote: > >>> On 03/04/2015 01:00, Bernd Paysan wrote: > >>>> Question: How many people need a 32 bit Gforth on Windows? Is there any > >>>> demand for that or is the 64 bit Gforth just fine? AMD64 has been > >>>> introduced more than 10 years ago, and Windows XP has reached EOL; if you > >>>> want to be vintage, you can as well use the old Gforth 0.7 executable > >>>> ;-). > >>> > >>> I still use 32 bit Windows 7, I've never felt the need to move to 64 > >>> bits and probably won't until I get a new computer. > >>> > >> > >> I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived > >> advantage of going 64-bit beyond generally "keeping up with fashion"? > >> > >> Cheers, > >> Elizabeth > >> > > > > "All programming is an exercise in caching."; Terje Mathisen. Way back > > when I was a lad, 16 bit programs had overlays and all sorts of > > segmentation trickery to get round a much smaller limit, and 32 bits > > looked like luxury. Now, not so much. Addressing beyond the 4GB limit > > (and some OSes limit 32bit apps to less) of memory as a cache makes > > programming much easier. > > > > Yes, but it makes programs run much slower. Back in the 16-bit era we > were able to out-perform a number of programs because Forth applications > were so much smaller than programs written other ways, and a very major > factor was the lack of necessity for caching. So far, since going to > 32-bit systems in the 80's, we haven't seen a need for caching in 32-bit > address space. You weren't out-performing anybody --- that is just a salesperson's fantasy. Back in the 16-bit era, PolyForth was limited to 64KB total --- this included the application program, the application data, the compiler, the dictionary, the editor --- everything! This was much worse than the Tiny memory-model used in C for .COM files, because in C only the application program and application data had to fit in 64KB. Because PolyForth programs were in such a restricted memory space (a single 64KB segment), they typically used binary overlays extensively --- somewhat like building a ship in a bottle --- but this kills the speed of the program. For building .COM files, I used TCOM --- this was similar to C in that it used the Tiny memory-model --- the compiler, dictionary and editor were not in the 64KB as they were in PolyForth --- only the application program and data --- so I could build much bigger programs than you could, and they were much faster because they were STC rather than ITC. UR/Forth used "segmentation trickery" (Alex McDonald's term) --- this involved using the segment registers of the 8086 --- DS pointed to a 64KB block containing data and threaded code, CS pointed to a 64KB block containing machine-code, and ES pointed to the dictionary. This resulted in UR/Forth code being much faster than PolyForth code --- with a full 64KB for machine-code, there could be a lot more primitives --- also, UR/Forth was DTC and PolyForth was ITC. According to my own tests, UR/Forth was very comparable to Turbo C (Small memory-model) both in terms of how big the programs could be and how fast they ran. PolyForth was generally considered to be inferior to Qbasic. It was slower, it provided less memory for the application program, and it lacked basic features such as arrays. I'm not aware of anybody who took PolyForth seriously. So, why didn't PolyForth use the segment registers? Most likely, the 8086-version of PolyForth was ported directly from the old PDP-11 version. Nobody at Forth Inc. was capable of figuring out how the segment registers worked --- all they could manage was a line-by-line port of Charles Moore's old program from the 1970s.
[toc] | [prev] | [next] | [standalone]
| From | Johan Kotlinski <kotlinski@gmail.com> |
|---|---|
| Date | 2015-04-03 23:57 -0700 |
| Message-ID | <244d7af2-d559-44aa-83e8-640edf4d6b2d@googlegroups.com> |
| In reply to | #37899 |
> I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived > advantage of going 64-bit beyond generally "keeping up with fashion" Hi Elizabeth, AMD64 has 16 general-purpose registers instead of 8 for x386. Those additional registers can be very useful when writing high-performance DSP code. But I guess it is not easy to make good use of those additional registers from a standard Forth environment..? Regards Johan
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-04-03 21:35 -1000 |
| Message-ID | <CN6dncBhe9yuCYLInZ2dnUU7-L2dnZ2d@supernews.com> |
| In reply to | #37917 |
On 4/3/15 8:57 PM, Johan Kotlinski wrote: >> I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived >> advantage of going 64-bit beyond generally "keeping up with fashion" > > Hi Elizabeth, > AMD64 has 16 general-purpose registers instead of 8 for x386. Those > additional registers can be very useful when writing high-performance > DSP code. But I guess it is not easy to make good use of those > additional registers from a standard Forth environment..? Sure it is! Register utilization is critical to getting good performance. FORTH, Inc. has traditionally allocated registers such that most have recognized system functions and several are left as scratch registers, that can be used without saving and restoring. In traditional ITC Forths, we had: S - Data stack pointer R - Return stack pointer I - Address interpreter pointer (next address to be executed) U - User pointer (multitasker) ...and one or two available accumulators. If there are extra registers: T - Top stack value N - Next stack value ...maybe more available accumulators. With modern native code compilers, we can make even better use of multiple registers. But going to a 64-bit design is a lot of work for only a few more registers if you have no pressing need for the address space. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2015-04-04 10:00 -0700 |
| Message-ID | <70c5fff1-af55-4f75-8356-59bd58bebd81@googlegroups.com> |
| In reply to | #37917 |
The older 32 bit processors are not going away anytime soon. They will find their uses in embedded systems. Even the forty year old 8-bit z80 and 6502 processors, or variants, are produced and used today. Keeping 32-bit versions of Forth systems around, even if they are ported to 64 bits, seems sensible. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-04-04 19:08 +0200 |
| Message-ID | <20150404190831.3cbe961d@maxa-pc> |
| In reply to | #37917 |
On Fri, 3 Apr 2015 23:57:10 -0700 (PDT) Johan Kotlinski <kotlinski@gmail.com> wrote: > > I use 32-bit Forth on 64-bit Win7 and MacOS. What is the perceived > > advantage of going 64-bit beyond generally "keeping up with fashion" > > Hi Elizabeth, > AMD64 has 16 general-purpose registers instead of 8 for x386. Those > additional registers can be very useful when writing high-performance > DSP code. But I guess it is not easy to make good use of those > additional registers from a standard Forth environment..? > > Regards > Johan Linux has x32 binaries which take advantage of additional registers while keeping memory footprint 32 bit. http://en.wikipedia.org/wiki/X32_ABI
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-04-02 22:45 +0200 |
| Message-ID | <ea46cgsfl2d8.kavkz88onzqa.dlg@40tude.net> |
| In reply to | #37834 |
Op Thu, 2 Apr 2015 12:38:10 +0200 schreef Coos Haak: > Op Thu, 02 Apr 2015 05:27:52 +0200 schreef Bernd Paysan: > >> Bernd Paysan wrote: >> >>> Bernd Paysan wrote: >>> >>>> Alex McDonald wrote: >>>>> I've tried in the distant past, but unsuccesfully. Let me know what the >>>>> steps are and I'll install the tools and attempt it again. >> >> I finally managed to compile it with the 64 bit Cygwin version (some old >> mmap bug of Cygwin apparently made it into Cygwin64, and the old fix >> fortunately works there ;-). If you want to try, an "inofficial" snapshot >> is now here: >> >> http://bernd-paysan.de/gforth-0.7.9_20150221.exe >> >> If someone confirms that it works, I'll make it an official snapshot >> (probably after updating the snapshot date). > > I tried, but failed to download. Norton Internet Security deleted it and > thinks that WS.Reputation.1 is the origin of the thread. I must say, the tar.gz compiled just fine under cygwin (32, I've not yet installed cygwin 64 on my new machine) Of course, VBOX with ubuntu-32 and -64 accept gforth-0.7.9_20150221 and ciforth 5.1. Swiching to MacAfee may solve my problem, as Alex McDonald confirms. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web