Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42901 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-10-28 09:04 -0700 |
| Last post | 2015-12-12 18:52 -0800 |
| Articles | 20 on this page of 174 — 27 participants |
Back to article view | Back to comp.lang.forth
Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:04 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:18 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 12:35 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:54 -0700
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-28 10:35 -0700
Re: Stoked Jason Damisch <jasondamisch@yahoo.com> - 2015-10-28 11:21 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 14:24 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 13:12 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-28 16:31 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 14:55 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 01:36 -0400
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-10-30 06:01 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 13:22 -0400
Re: Stoked Marcos Cruz <use_the_contact_page@programandala.net> - 2015-11-07 17:50 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 13:04 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 10:19 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 08:29 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-11-07 13:28 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 13:33 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 16:40 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 14:25 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 18:03 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 15:22 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 01:13 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 22:35 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 01:58 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-07 23:17 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 02:49 -0500
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-08 00:06 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 01:40 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 15:18 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 13:31 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 17:19 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-11 20:49 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 00:57 -0500
Re: Stoked hughaguilar96@gmail.com - 2015-11-11 22:24 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-11 23:34 -0800
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-12 00:03 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 19:37 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 15:24 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 13:18 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-12 16:40 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 20:59 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-13 01:50 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 23:11 -0800
Re: Stoked forthisit@gmail.com - 2015-11-12 13:47 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-12 16:27 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-12 12:18 -1000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-13 00:28 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-11 22:37 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-11-12 23:37 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:19 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 07:47 +0100
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-23 11:27 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-23 13:43 +0100
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 12:49 -1000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 19:20 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:44 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 18:23 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 10:32 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 18:45 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 10:53 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 21:25 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 14:09 -0800
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-09 05:32 -0500
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:58 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 23:42 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 21:11 -0800
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-15 12:50 +0100
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-07 23:56 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 03:24 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 01:31 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:57 -1000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 02:18 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 08:33 -1000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 00:07 -0500
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-08 23:49 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 21:06 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 00:20 -0500
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-08 22:51 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-09 02:22 -0500
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-11-10 04:32 -0800
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-10 13:48 +0000
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-10 16:17 -0500
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-10 17:26 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-08 21:50 -1000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-11-09 12:15 +0000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 15:09 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 09:47 +0100
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-11-24 12:54 +0000
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-24 15:03 +0100
Emulating a 16-bit Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 13:18 +0100
Re: Emulating a 16-bit Forth Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 14:08 +0100
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-09 14:30 +0000
Re: Stoked Bernd Linsel <bl1@gmx.com> - 2015-11-09 18:27 +0100
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-10 00:50 -0800
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:52 -1000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:16 -1000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 23:07 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 17:58 +0000
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-11-07 12:00 -1000
Re: Stoked Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-11-08 17:49 +0000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-28 23:24 +0000
Re: Stoked Jason Damisch <jasondamisch@yahoo.com> - 2015-10-28 17:30 -0700
Re: Stoked Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-10-29 02:40 +0000
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:11 +0000
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:07 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 21:16 -0700
Re: Stoked franck.bensusan@gmail.com - 2015-10-29 01:35 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-29 10:16 +0000
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-29 03:35 -0700
Re: Stoked lehs <skydda.barnen@gmail.com> - 2015-10-29 03:48 -0700
Re: Stoked mhx@iae.nl - 2015-10-29 11:31 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-29 12:01 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-29 12:26 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 15:29 -0400
Re: Stoked mhx@iae.nl - 2015-10-29 13:27 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-29 16:48 -0400
Re: Stoked josv@planet.nl - 2015-10-29 14:58 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 01:36 -0400
Re: Stoked josv@planet.nl - 2015-10-30 04:34 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 13:28 -0400
Re: Stoked josv@planet.nl - 2015-10-30 12:05 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 15:32 -0400
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 18:53 -1000
Re: Stoked josv@planet.nl - 2015-11-01 04:28 -0800
Re: Stoked hughaguilar96@gmail.com - 2015-11-03 22:27 -0800
Re: Stoked mhx@iae.nl - 2015-10-29 16:47 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 01:33 -0400
Re: Stoked mhx@iae.nl - 2015-10-31 00:55 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-30 11:52 +0000
Re: Stoked josv@planet.nl - 2015-10-29 14:49 -0700
Re: Stoked stephen@mpeforth.com (Stephen Pelc) - 2015-10-30 11:50 +0000
Re: Stoked Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 18:39 +0100
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 11:11 -0700
Re: Stoked Hans Bezemer <the.beez.speaks@gmail.com> - 2015-10-28 20:01 +0100
Re: Stoked hughaguilar96@gmail.com - 2015-10-28 12:34 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 13:09 -0700
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-10-28 15:25 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:01 -0700
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-29 01:58 -0400
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-10-28 23:34 -0700
Re: Stoked Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-29 08:56 +0100
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-10-28 18:41 -0400
Re: Stoked josv@planet.nl - 2015-10-29 05:28 -0700
Re: Stoked "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-12-12 11:25 -0500
Re: Stoked "Elizabeth D. Rather" <erather@forth.com> - 2015-12-12 08:43 -1000
Re: Stoked hughaguilar96@gmail.com - 2015-12-16 13:45 -0800
Re: Stoked hughaguilar96@gmail.com - 2015-12-17 10:26 -0800
Re: Stoked Rob Sciuk <rob@controlq.com> - 2015-12-13 23:29 -0500
Re: Stoked Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-13 22:31 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 15:52 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-29 16:57 +0000
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-29 12:36 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-31 14:57 +0000
Re: Stoked Bernd Paysan <bernd.paysan@gmx.de> - 2015-10-31 20:25 +0100
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-11-03 20:39 -0800
Re: Stoked Pablo Hugo Reda <pabloreda@gmail.com> - 2015-10-28 16:27 -0700
Re: Stoked Alfred Singlestone <vitonis@gmail.com> - 2015-10-30 05:57 -0700
Re: Stoked "HAA" <someone@microsoft.com> - 2015-11-02 13:15 +1100
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-11-02 02:08 -0800
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 09:28 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 09:37 -0700
Re: Stoked Paul Rubin <no.email@nospam.invalid> - 2015-10-28 10:28 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 10:52 -0700
Re: Stoked anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-28 18:14 +0000
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-10-28 15:20 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-28 21:16 -0700
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-10-30 12:13 -0700
Re: Stoked rickman <gnuarm@gmail.com> - 2015-10-30 15:34 -0400
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-11-07 13:57 -0800
Re: Stoked rickman <gnuarm@gmail.com> - 2015-11-07 17:19 -0500
Re: Stoked François <francois.ganza@wanadoo.fr> - 2015-11-09 00:10 -0800
Re: Stoked Chris Curl <ccurl609@gmail.com> - 2015-12-12 18:52 -0800
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-08 18:45 +0000 |
| Message-ID | <563f9862$0$23795$e4fe514c@news.xs4all.nl> |
| In reply to | #43378 |
Paul Rubin <no.email@nospam.invalid> writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >> I find it very hard to imagine an assembler that doesn't relies on >> stuff running on a host computer, in particular files (punched tape?) >I thought almost all small Forths contained their own assemblers, for >example to be able to interactively define CODE words. I forgot about >that last night. But once you have that, why not use it for building? You said it right: interactively. You don't want to supply the source of your new forth interactively. You want it in files. Welcome host system. <SNIP> 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 10:53 -0800 |
| Message-ID | <87r3k0tj9k.fsf@nightsong.com> |
| In reply to | #43380 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes: > You said it right: interactively. You don't want to supply the source > of your new forth interactively. You want it in files. Welcome host > system. Were blocks really so terrible? Maybe they were--I've never used them. But there are still people who like them and use them. The Greenarrays stuff is all written with blocks, and Sam Falvo's blog program used them too. Anyway, if you can have blocks on the target, you can have files with a little more code.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-08 21:25 +0000 |
| Message-ID | <563fbdc2$0$23776$e4fe514c@news.xs4all.nl> |
| In reply to | #43382 |
Paul Rubin <no.email@nospam.invalid> writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >> You said it right: interactively. You don't want to supply the source >> of your new forth interactively. You want it in files. Welcome host >> system. >Were blocks really so terrible? Maybe they were--I've never used them. >But there are still people who like them and use them. The Greenarrays >stuff is all written with blocks, and Sam Falvo's blog program used them >too. No, colorforth was written in assembler. Once it was there you can bootstrap into improved systems, but you cannot overhaul it. I advise against trying to do something in colorforth, but e.g. changing it to a 64 bit system is virtually impossible. I've disassembled colorforth, and I can reassemble it. I'm in a better position to change it to 64 bits than Greenarrays. Most feats around colorforth lean heavily on files and source control systems. >Anyway, if you can have blocks on the target, you can have files with a >little more code. I've done that. Bootstrapped into a system with a forth in the master boot record and the ability to use blocks from there. It had the best forth editor for blocks you've ever seen. You're not my worst enemy, and even then I wouldn't wish you to type in the source for the next version into those blocks. P.S. I don't hate blocks. They have excellent modularity that fits Forth well. I use them for library code in ciforth. 1 block for formatting, 1 block for OO, 1 block for totient, choose and tridiagonal functions, couple of blocks for mergesort, couple of blocks for qsort, 2 blocks for bags/sets etc. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 14:09 -0800 |
| Message-ID | <87io5cta72.fsf@nightsong.com> |
| In reply to | #43386 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>The Greenarrays stuff is all written with blocks > No, colorforth was written in assembler. .. I've disassembled colorforth Oh ok, that's the PC-hosted compiler. I meant the the actual GA144 rom code, which uses blocks. Chuck did release the asm source code for Colorforth by the way. > It had the best forth editor for blocks you've ever seen. > You're not my worst enemy, and even then I wouldn't wish you > to type in the source for the next version into those blocks. Polyforth used blocks--was that equally bad? Of course you'd want a way to upload and download the whole contents of the target storage. I'm imagining something like 4e4th except for a chip with more memory (ram and flash) than the MSP430G2553. So instead of just having an interactive interpreter, the whole system could be there as source code and dev environment, and could rebuild itself. The MSP430FR6989 has 128KB of FRAM which might be enough for this, and there's a very nice Launchpad board built around it.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-11-09 05:32 -0500 |
| Message-ID | <op.x7twwwkdyfako5@localhost> |
| In reply to | #43386 |
On Sun, 08 Nov 2015 16:25:22 -0500, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > I've done that. Bootstrapped into a system with a forth in the > master boot record and the ability to use blocks from there. > It had the best forth editor for blocks you've ever seen. > You're not my worst enemy, and even then I wouldn't wish you > to type in the source for the next version into those blocks. Was this for x86? How big was the bootstrap system in bytes? Rod Pemberton -- When El Chapo is the most beloved man in Mexico and Trump is the most hated, it shows that Mexico is truly fouled up.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-09 14:58 +0000 |
| Message-ID | <5640b4aa$0$23832$e4fe514c@news.xs4all.nl> |
| In reply to | #43419 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes: >On Sun, 08 Nov 2015 16:25:22 -0500, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> I've done that. Bootstrapped into a system with a forth in the >> master boot record and the ability to use blocks from there. >> It had the best forth editor for blocks you've ever seen. >> You're not my worst enemy, and even then I wouldn't wish you >> to type in the source for the next version into those blocks. >Was this for x86? Yes, for 32 bits (386+). However all I/O switched back to real mode for disk screen keyboard. That didn't prevent it to access all 300,000 blocks of a 300 Mbyte disk. >How big was the bootstrap system in bytes? 310 kbyte for the floppy image, that can be installed on hd too. 310 kbyte is mostly source blocks. The actual code is 33 kbyte. See ciforth.html on the site in my sig. From that file a caveat: " Booting using the BIOS is tricky. Approximately one out of three installation fails. " On modern systems that could be more failure. But if you have a windows 98 SE machine hanging around ... >Rod Pemberton 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 23:42 -0500 |
| Message-ID | <n1p82g$4tv$1@dont-email.me> |
| In reply to | #43382 |
On 11/8/2015 1:53 PM, Paul Rubin wrote: > Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >> You said it right: interactively. You don't want to supply the source >> of your new forth interactively. You want it in files. Welcome host >> system. > > Were blocks really so terrible? Maybe they were--I've never used them. > But there are still people who like them and use them. The Greenarrays > stuff is all written with blocks, and Sam Falvo's blog program used them > too. > > Anyway, if you can have blocks on the target, you can have files with a > little more code. Then with a little more code you can create a USB interface or an Ethernet interface or... wait! The processor I'm using doesn't have *any* of that including the many 100's of KBs of flash. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 21:11 -0800 |
| Message-ID | <87611bu57q.fsf@nightsong.com> |
| In reply to | #43400 |
rickman <gnuarm@gmail.com> writes: > Then with a little more code you can create a USB interface or an > Ethernet interface or... wait! The processor I'm using doesn't have > *any* of that including the many 100's of KBs of flash. You mean the Stellaris Launchpad? That has 256k of flash and USB, I thought. I do get the point that current small MCU's don't really have the space for this.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-15 12:50 +0100 |
| Message-ID | <86wptj32ht.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43378 |
Paul Rubin <no.email@nospam.invalid> writes: > I see metacompilation as one of the fiendishly clever techniques that > makes Forth interesting. A Forth written for enjoyment from this > perspective should certainly use it, come what may. I agree!
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-11-07 23:56 -0800 |
| Message-ID | <a36bbee3-cf47-4a17-99f2-7762981ec44e@googlegroups.com> |
| In reply to | #43341 |
duminică, 8 noiembrie 2015, 08:13:55 UTC+2, rickman a scris: > On 11/7/2015 6:22 PM, Paul Rubin wrote: > > rickman <gnuarm@gmail.com> writes: > >> What operations will exceed the capacity of a 16 bit cell. > > > > 100000 200000 + > > Is that required to write a Forth? > For a 16bit forth this is impossible. (You need to write 100000 200000 D+ but this is different). So, you need a 32bit forth for MSP430. Noone has done that, so you write it yourself. 100000 200000 D+ On 32bit systems this is a 64bit addition. On 16bit ones this is just the (intended) 32bit addition on double numbers. Maybe you want to port your 16bit applications to a modern cortex-m cpu "as is". You need a 16bit forth on a cortex-m cpu. Nobody has done that, so you write it yourself.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 03:24 -0500 |
| Message-ID | <n1n0oa$acb$1@dont-email.me> |
| In reply to | #43347 |
On 11/8/2015 2:56 AM, Raimond Dragomir wrote: > duminică, 8 noiembrie 2015, 08:13:55 UTC+2, rickman a scris: >> On 11/7/2015 6:22 PM, Paul Rubin wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> What operations will exceed the capacity of a 16 bit cell. >>> >>> 100000 200000 + >> >> Is that required to write a Forth? >> > > For a 16bit forth this is impossible. (You need to write 100000 200000 D+ but this is different). > So, you need a 32bit forth for MSP430. Noone has done that, so you write it > yourself. Can't I just make a few changes to an existing forth by loading a file which makes the required operators 32 bit? In VHDL we call this overloading. I don't think I need to write my own forth interpreter to do 32 bit arithmetic on a 16 bit processor. : + D+ ; etc... > 100000 200000 D+ > On 32bit systems this is a 64bit addition. On 16bit ones this is just the > (intended) 32bit addition on double numbers. Maybe you want to port your > 16bit applications to a modern cortex-m cpu "as is". You need a 16bit forth > on a cortex-m cpu. Nobody has done that, so you write it yourself. In this case, why do I care that the cell size is 32 bits rather than 16? Since when will a 16 bit application not work on a 32 bit forth? I think any ANS compliant code will run in this case, no? If you aren't talking ANS compliant code, then why would you expect it to port anyway? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 01:31 -0800 |
| Message-ID | <87d1vkvnvc.fsf@nightsong.com> |
| In reply to | #43349 |
rickman <gnuarm@gmail.com> writes: > Can't I just make a few changes to an existing forth by loading a file > which makes the required operators 32 bit? > : + D+ ; etc... Maybe something like that can help, but remember SWAP becomes 2SWAP, 2SWAP becomes 4SWAP etc. 2OVER becomes something that juggles 12 stack cells! But that's probably about the worst, so it's enough to just have a static dozen cells of memory set aside for those operations. And there's the presumption on a 32 bit system that a cell is 4 bytes, which gets weird on a 16 bit system. Bit operations are also ugly, e.g. rotating a 32-bit word by 7 bits in a 16-bit Forth. Using asm primitives would surely be nicer. > In this case, why do I care that the cell size is 32 bits rather than > 16? Since when will a 16 bit application not work on a 32 bit forth? > I think any ANS compliant code will run in this case, no? The only way to know is to try it. Maybe I can write some 16 bit code and test it on a 32 bit system, but I'd also need to test it on a 16 bit system, and right now I don't know of a 16 bit Forth that works on any of the computers I have available (x86 and ARM).
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-07 23:57 -1000 |
| Message-ID | <LpednXnA_okegaLLnZ2dnUU7-TednZ2d@supernews.com> |
| In reply to | #43352 |
On 11/7/15 11:31 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Can't I just make a few changes to an existing forth by loading a file >> which makes the required operators 32 bit? >> : + D+ ; etc... > > Maybe something like that can help, but remember SWAP becomes 2SWAP, > 2SWAP becomes 4SWAP etc. 2OVER becomes something that juggles 12 stack > cells! But that's probably about the worst, so it's enough to just have > a static dozen cells of memory set aside for those operations. And > there's the presumption on a 32 bit system that a cell is 4 bytes, which > gets weird on a 16 bit system. > > Bit operations are also ugly, e.g. rotating a 32-bit word by 7 bits > in a 16-bit Forth. Using asm primitives would surely be nicer. > >> In this case, why do I care that the cell size is 32 bits rather than >> 16? Since when will a 16 bit application not work on a 32 bit forth? >> I think any ANS compliant code will run in this case, no? > > The only way to know is to try it. Maybe I can write some 16 bit code > and test it on a 32 bit system, but I'd also need to test it on a 16 bit > system, and right now I don't know of a 16 bit Forth that works on any > of the computers I have available (x86 and ARM). In the 70's, FORTH, Inc. had quite a number of customers upgrading applications from 16-bit systems to 32-bit systems. It really was quite easy; the only problem was identifying all the times they said "2 +" with addresses instead of CELL+ and that sort of thing. Nowadays CELL+ and friends are over 21 years old, all grown up, nobody should have such problems. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 02:18 -0800 |
| Message-ID | <874mgwvlp5.fsf@nightsong.com> |
| In reply to | #43356 |
"Elizabeth D. Rather" <erather@forth.com> writes: > In the 70's, FORTH, Inc. had quite a number of customers upgrading > applications from 16-bit systems to 32-bit systems. It really was > quite easy; the only problem was identifying all the times they said > "2 +" with addresses instead of CELL+ and that sort of thing. As a possible example, my application requires a lot of bit rotations on 32-bit words. That's kind of contorted on a 16 bit system, but say I manage to do it, probably using D2* and D2/ and extracting the top and bottom bits a lot. What happens when I port it to a 32 bit system?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-08 08:33 -1000 |
| Message-ID | <uYadnSI9HI_tCKLLnZ2dnUU7-XmdnZ2d@supernews.com> |
| In reply to | #43358 |
On 11/8/15 12:18 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> In the 70's, FORTH, Inc. had quite a number of customers upgrading >> applications from 16-bit systems to 32-bit systems. It really was >> quite easy; the only problem was identifying all the times they said >> "2 +" with addresses instead of CELL+ and that sort of thing. > > As a possible example, my application requires a lot of bit rotations on > 32-bit words. That's kind of contorted on a 16 bit system, but say I > manage to do it, probably using D2* and D2/ and extracting the top and > bottom bits a lot. What happens when I port it to a 32 bit system? > It would probably work but be inefficient, which may or may not be a problem. If it turns out to be a problem, then you can write a 32-bit or target-specific version. Your decision will have a lot to do with whether your intention is to retain backwards compatibility with 16-bit systems or not. Sometimes that's important, often not. That's the kind of function that IMO should probably be done in code anyway, if you're concerned about performance. Strategically, if most of your program is portable and certain functions (presumably clearly identified in target-specific files) are not, then porting is straightforward. There are, in the real world, very few programs of any size that do not have certain dependencies. The survival strategy for programmers is to clearly identify and isolate them in such a way that adaptation will be clean and free from side-effects. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-09 00:07 -0500 |
| Message-ID | <n1p9it$8gm$1@dont-email.me> |
| In reply to | #43358 |
On 11/8/2015 5:18 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> In the 70's, FORTH, Inc. had quite a number of customers upgrading >> applications from 16-bit systems to 32-bit systems. It really was >> quite easy; the only problem was identifying all the times they said >> "2 +" with addresses instead of CELL+ and that sort of thing. > > As a possible example, my application requires a lot of bit rotations on > 32-bit words. That's kind of contorted on a 16 bit system, but say I > manage to do it, probably using D2* and D2/ and extracting the top and > bottom bits a lot. What happens when I port it to a 32 bit system? I'm not sure what your point is. If you have coded your app to do 32 bit operations using 16 bit cells then you have coded a hardware dependency into your code. ANS Forth programs should be coded to be independent of cell size. Then it is portable between CPUs with no worries. Even so, if you have written your app to do 32 bit ops using 16 bit operators how will custom writing a forth help this? Oh, rather than rewrite the app, or to write a 16 bit interface for the 32 bit interpreter, it is simpler to write a 16 bit forth from the ground up for a 32 bit CPU. Hard to imagine. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-08 23:49 -0500 |
| Message-ID | <n1p8g9$5t1$1@dont-email.me> |
| In reply to | #43352 |
On 11/8/2015 4:31 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> Can't I just make a few changes to an existing forth by loading a file >> which makes the required operators 32 bit? >> : + D+ ; etc... > > Maybe something like that can help, but remember SWAP becomes 2SWAP, > 2SWAP becomes 4SWAP etc. 2OVER becomes something that juggles 12 stack > cells! But that's probably about the worst, so it's enough to just have > a static dozen cells of memory set aside for those operations. And > there's the presumption on a 32 bit system that a cell is 4 bytes, which > gets weird on a 16 bit system. > > Bit operations are also ugly, e.g. rotating a 32-bit word by 7 bits > in a 16-bit Forth. Using asm primitives would surely be nicer. Whatever words are involved can be recoded to work on 32 bit operands. Surely this is easier to do in forth than it is to rewrite the entire forth interpreter. >> In this case, why do I care that the cell size is 32 bits rather than >> 16? Since when will a 16 bit application not work on a 32 bit forth? >> I think any ANS compliant code will run in this case, no? > > The only way to know is to try it. Maybe I can write some 16 bit code > and test it on a 32 bit system, but I'd also need to test it on a 16 bit > system, and right now I don't know of a 16 bit Forth that works on any > of the computers I have available (x86 and ARM). I'm not sure what you are saying. If you don't have a 16 bit app, why do you need to worry about running it on a 32 bit machine? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 21:06 -0800 |
| Message-ID | <87a8qnu5g7.fsf@nightsong.com> |
| In reply to | #43401 |
rickman <gnuarm@gmail.com> writes: > I'm not sure what you are saying. If you don't have a 16 bit app, why > do you need to worry about running it on a 32 bit machine? Immediate inspiration: I'm interested in running an app (not yet written) on a TI MSP430, that uses a 16 bit CPU. I'd prefer to write and debug the computational part of the app on a Linux box for greater convenience. Right now there doesn't seem to be any 16-bit Forth for Linux. So the choices are: 1) write and test on 32-bit Linux Forth, then run on the MSP under some kind of 32-bit Forth (not currently known to exist). 2) somehow conjure up a 16 bit Linux Forth, write and test under that, then transfer the program to a 16-bit MSP Forth (there are lots of those). 3) Write under 32-bit Forth with the intention of being portable to 16 bit, transfer it to the MSP and hope for the best. This sounds to me like a recipe for bugs and hassles. You can see the problems with each approach. They would all go away with a Forth that let you set the cell size independently of the hardware. Is it worth developing such a thing for the sake of this one fairly simple app? Nah. But it might have more general usefulness.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-09 00:20 -0500 |
| Message-ID | <n1paaq$a79$1@dont-email.me> |
| In reply to | #43402 |
On 11/9/2015 12:06 AM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >> I'm not sure what you are saying. If you don't have a 16 bit app, why >> do you need to worry about running it on a 32 bit machine? > > Immediate inspiration: I'm interested in running an app (not yet > written) on a TI MSP430, that uses a 16 bit CPU. I'd prefer to write > and debug the computational part of the app on a Linux box for greater > convenience. Right now there doesn't seem to be any 16-bit Forth for > Linux. So the choices are: > > 1) write and test on 32-bit Linux Forth, then run on the MSP under > some kind of 32-bit Forth (not currently known to exist). > > 2) somehow conjure up a 16 bit Linux Forth, write and test under that, > then transfer the program to a 16-bit MSP Forth (there are lots of > those). > > 3) Write under 32-bit Forth with the intention of being portable to 16 > bit, transfer it to the MSP and hope for the best. This sounds to me > like a recipe for bugs and hassles. > > You can see the problems with each approach. They would all go away > with a Forth that let you set the cell size independently of the > hardware. Is it worth developing such a thing for the sake of this one > fairly simple app? Nah. But it might have more general usefulness. Why can't you write the app to not be dependent on a particular cell size? This is not rocket science. The idea that you then have to "hope for the best" on the TMS430 is a bit naive. Why would you not fully test the app on every new platform you run on, same word size or not? I know my most annoying bugs have come from inadequate testing of code I have reused thinking it should work just fine. In fact, wasn't that the cause of bringing down one of the Ariane rockets? Code was ported but all of the conditions for its use were not identical, so it ended up having an error that shut down the processor and the rocket crashed. More analysis and testing would have found this problem. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-08 22:51 -0800 |
| Message-ID | <871tbzu0ly.fsf@nightsong.com> |
| In reply to | #43405 |
rickman <gnuarm@gmail.com> writes: > Why can't you write the app to not be dependent on a particular cell > size? This is not rocket science. I'm not persuaded that it's as easy as you make it sound. You might turn out to be right, but I'll believe it when I see it. > The idea that you then have to "hope for the best" on the TMS430 is a > bit naive. Why would you not fully test the app on every new platform > you run on, same word size or not? Of course I'd have to test it on the TMS430 since I ultimately want to USE it on the TMS430. "Hope for the best" means I'd test it and hope to find that it works on the first try and doesn't need any rewriting. That's the best. The non-best would involve some hours or days of annoying debugging, ironing out issues resulting from the CPU change. > I know my most annoying bugs have come from inadequate testing of code > I have reused thinking it should work just fine. Yes, that's precisely what I'm saying. I've experienced that many times myself and would expect more of the same in this scenario. It's easier if the two cpus have the same word size, byte order in a word, etc.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web