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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-11-09 02:22 -0500 |
| Message-ID | <n1phfj$t2d$1@dont-email.me> |
| In reply to | #43407 |
On 11/9/2015 1:51 AM, Paul Rubin wrote: > 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. Ok, let us know when you are done... :) >> 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. Actually, I'm not sure why it would be any better to debug the code on a different platform. Do you have some special debugging tools on the Linux box? What makes this more convenient? >> 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. Uh, if you test the code, it wouldn't be inadequate testing... I work exactly in the mode you seem to think is so problematic, use a PC for editing, file storage and use the target to compile and test code. I found few problems once I got running. My biggest one was that crashing the target required me to go to the other room since I was working remotely. I plan to rig up something on the rPi to let me cycle power to the target. I'm going to bring up another target with Mecrisp. We'll see how that one works. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Alfred Singlestone <vitonis@gmail.com> |
|---|---|
| Date | 2015-11-10 04:32 -0800 |
| Message-ID | <ba091c81-ec88-4753-901e-8ed5f1febea5@googlegroups.com> |
| In reply to | #43405 |
On Monday, November 9, 2015 at 12:20:35 AM UTC-5, rickman wrote: > Why can't you write the app to not be dependent on a particular cell > size? I know this doesn't touch on the idea of writing an *app* without a dependence on cell size, but: I started with Jonesforth as a base. One of the first things I did was convert it to 64-bit. There were literal 4s sprinkled everywhere. Now I have: %define CELL qword %define RESC resq %define LODSC lodsq %define STOSC stosq struc cell .dummy: RESC 1 endstruc ... etc. The language being NASM, "struc cell/endstruc" automatically gives you a cell_size equate, with which I immediately replaced the cussed hard-coded 4s. Want to go back to 32-bit? Use "d" instead of "q" in the defines, and many of the changes are made for you automatically. Not too hard. But the first conversion was paaaainful.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-10 13:48 +0000 |
| Message-ID | <5641f597$0$23856$e4fe514c@news.xs4all.nl> |
| In reply to | #43448 |
Alfred Singlestone <vitonis@gmail.com> writes: >On Monday, November 9, 2015 at 12:20:35 AM UTC-5, rickman wrote: >> Why can't you write the app to not be dependent on a particular cell >> size? > know this doesn't touch on the idea of writing an *app* without a >ependence on cell size, but: I started with Jonesforth as a base. One >f the first things I did was convert it to 64-bit. There were literal >s sprinkled everywhere. Now I have: Please limit your lines to 72 characters. I've done it for you now, badly. You realize that jonesforth used ciforth loosely as a base? >%define CELL qword >%define RESC resq >%define LODSC lodsq >%define STOSC stosq >struc cell > .dummy: RESC 1 >endstruc I you'd start from ciforth you would have discovered that this has been done in the width64.m4 include file. You could've started from the ciforth 64bit,nasm configured file (after I applied those conversions and the configuration for MASM for you) and would have a system very simular to jonesforth but with better ISO compatibility. You could've used the generic system and adapted it. Then you would have tests, pdf and html docs as well. >... etc. The language being NASM, "struc cell/endstruc" automatically >gives you a cell_size equate, with which I immediately replaced the >cussed hard-coded 4s. >Want to go back to 32-bit? Use "d" instead of "q" in the defines, and >many of the changes are made for you automatically. Not too hard. But >the first conversion was paaaainful. I remembered doing that. I'm fluent with regular expressions and found it not too hard. 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-10 16:17 -0500 |
| Message-ID | <n1tmpj$2q4$2@dont-email.me> |
| In reply to | #43449 |
On 11/10/2015 8:48 AM, Albert van der Horst wrote: > Alfred Singlestone <vitonis@gmail.com> writes: > >> On Monday, November 9, 2015 at 12:20:35 AM UTC-5, rickman wrote: >>> Why can't you write the app to not be dependent on a particular cell >>> size? > >> know this doesn't touch on the idea of writing an *app* without a >> ependence on cell size, but: I started with Jonesforth as a base. One >> f the first things I did was convert it to 64-bit. There were literal >> s sprinkled everywhere. Now I have: > > Please limit your lines to 72 characters. I've done it for you now, > badly. > > You realize that jonesforth used ciforth loosely as a base? > >> %define CELL qword >> %define RESC resq > >> %define LODSC lodsq >> %define STOSC stosq > >> struc cell >> .dummy: RESC 1 >> endstruc > > I you'd start from ciforth you would have discovered that this has > been done in the width64.m4 include file. You could've started from > the ciforth 64bit,nasm configured file (after I applied those > conversions and the configuration for MASM for you) and would have a > system very simular to jonesforth but with better ISO compatibility. > You could've used the generic system and adapted it. Then you would > have tests, pdf and html docs as well. > >> ... etc. The language being NASM, "struc cell/endstruc" automatically >> gives you a cell_size equate, with which I immediately replaced the >> cussed hard-coded 4s. > >> Want to go back to 32-bit? Use "d" instead of "q" in the defines, and >> many of the changes are made for you automatically. Not too hard. But >> the first conversion was paaaainful. > > I remembered doing that. I'm fluent with regular expressions and found > it not too hard. If you are going to butcher the quotes so that they can't be read, maybe you just shouldn't quote them at all? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-11-10 17:26 -0500 |
| Message-ID | <op.x7womxbsyfako5@localhost> |
| In reply to | #43454 |
On Tue, 10 Nov 2015 16:17:49 -0500, rickman <gnuarm@gmail.com> wrote: > On 11/10/2015 8:48 AM, Albert van der Horst wrote: >> Alfred Singlestone <vitonis@gmail.com> writes: >>> On Monday, November 9, 2015 at 12:20:35 AM UTC-5, rickman wrote: >>>> Why can't you write the app to not be dependent on a particular cell >>>> size? >> >>> know this doesn't touch on the idea of writing an *app* without a >>> ependence on cell size, but: I started with Jonesforth as a base. One >>> f the first things I did was convert it to 64-bit. There were literal >>> s sprinkled everywhere. Now I have: >> >> Please limit your lines to 72 characters. I've done it for you now, >> badly. >> >> You realize that jonesforth used ciforth loosely as a base? >> >>> %define CELL qword >>> %define RESC resq >> >>> %define LODSC lodsq >>> %define STOSC stosq >> >>> struc cell >>> .dummy: RESC 1 >>> endstruc >> >> I you'd start from ciforth you would have discovered that this has >> been done in the width64.m4 include file. You could've started from >> the ciforth 64bit,nasm configured file (after I applied those >> conversions and the configuration for MASM for you) and would have a >> system very simular to jonesforth but with better ISO compatibility. >> You could've used the generic system and adapted it. Then you would >> have tests, pdf and html docs as well. >> >>> ... etc. The language being NASM, "struc cell/endstruc" automatically >>> gives you a cell_size equate, with which I immediately replaced the >>> cussed hard-coded 4s. >> >>> Want to go back to 32-bit? Use "d" instead of "q" in the defines, and >>> many of the changes are made for you automatically. Not too hard. But >>> the first conversion was paaaainful. >> >> I remembered doing that. I'm fluent with regular expressions and found >> it not too hard. > > If you are going to butcher the quotes so that they can't be read, maybe > you just shouldn't quote them at all? > If you're not going to wrap you're lines at all, maybe you shouldn't reply at all? Same logic. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-08 21:50 -1000 |
| Message-ID | <N-GdnRRQNq-gzd3LnZ2dnUU7-dGdnZ2d@supernews.com> |
| In reply to | #43402 |
On 11/8/15 7:06 PM, 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. > If you write your program assuming a "cell" is 16 bits and use CELLS, CELL+ etc. for addressing and 2 cells for every value that can be >32768 (with use of the 2's, D's and M's operators in arithmetic as needed), you're going to be pretty close. 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-11-09 12:15 +0000 |
| Message-ID | <56408caf.141582139@news.eternal-september.org> |
| In reply to | #43402 |
On Sun, 08 Nov 2015 21:06:48 -0800, Paul Rubin <no.email@nospam.invalid> wrote: >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. Our cross-compilers for 16 bit targets are hosted on a 32 bit Forth. We have some of these issues with double number arithmetic. The text interpreter within the cross-compiler special cases some words such as many in the double number word set. Similar hassles occur with floating point numbers. Item 2 is easy to do with a new vocabulary or word list. : + + $FFFF and ; ... Item 3 is actually the way to go in most cases. It will also teach you a lot about actual rather than theoretical aspects of Forth portability. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-09 15:09 +0000 |
| Message-ID | <5640b736$0$23832$e4fe514c@news.xs4all.nl> |
| In reply to | #43423 |
stephen@mpeforth.com (Stephen Pelc) writes: >On Sun, 08 Nov 2015 21:06:48 -0800, Paul Rubin ><no.email@nospam.invalid> wrote: >>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. >Our cross-compilers for 16 bit targets are hosted on a 32 bit Forth. >We have some of these issues with double number arithmetic. The >text interpreter within the cross-compiler special cases some >words such as many in the double number word set. Similar hassles >occur with floating point numbers. >Item 2 is easy to do with a new vocabulary or word list. >: + + $FFFF and ; >... >Item 3 is actually the way to go in most cases. It will also >teach you a lot about actual rather than theoretical aspects >of Forth portability. Another reality check. noforth (for the launchpad) is compiled on a 32 bits Forth (Win32forth) with attention to ISO compatibility, but little attention to cell-size. (Authors Willem Ouwerkerk and Albert Nijhof.) I made it compile on i.a. gforth 64 bit. That was not overly much work. A relative small part had to do with 32 versus 64 bit, in particular masks. I made the developers aware that someone might want to metacompile on a 64 bit system and now these issues have disappeared. I've made a post about that port. The largest headache turned out to be a difference between Windows and Linux source files. A metacompiler is a non-trivial piece of Forth, with more tricky aspects than a mere application. >Stephen 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 | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-24 09:47 +0100 |
| Message-ID | <86twobwzqi.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43423 |
Stephen Pelc wrote: > Paul Rubin wrote: >>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. >> >> 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). > > Item 2 is easy to do with a new vocabulary or word list. > > : + + $FFFF and ; > ... How would you easily implement @ in this vocabulary? Oh, I guess the "computational part" wouldn't need to be restricted to 16-bit addresses, so in that case it's really easy.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-11-24 12:54 +0000 |
| Message-ID | <56545d1a.82406342@news.eternal-september.org> |
| In reply to | #43701 |
On Tue, 24 Nov 2015 09:47:17 +0100, Lars Brinkhoff <lars.spam@nocrew.org> wrote: >Stephen Pelc wrote: >> >> : + + $FFFF and ; >> ... > >How would you easily implement @ in this vocabulary? > >Oh, I guess the "computational part" wouldn't need to be restricted to >16-bit addresses, so in that case it's really easy. If we are emulating a 16 bit CPU, then declare a 64k buffer and index into it. To allow for 16 bit access, assume that the 32 bit host has a word W@ ( addr -- x16 ). 64 kb buffer: vmem ... : @ ( addr16 -- x16 ) $FFFF and vmem + w@ ; The $FFFF and is redundant for correct programs. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-24 15:03 +0100 |
| Message-ID | <86egffwl44.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43701 |
>>>> 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. >>> >>> Item 2 [a 16-bit Forth] is easy to do with a new vocabulary or word >>> list. >> >> How would you easily implement @ in this vocabulary? > > If we are emulating a 16 bit CPU, then declare a 64k buffer and index > into it. To allow for 16 bit access, assume that the 32 bit host has a > word W@ ( addr -- x16 ). > > 64 kb buffer: vmem > > ... > > : @ ( addr16 -- x16 ) > $FFFF and vmem + w@ > ; The purpuse was to emulate a 16-bit Forth with a new vocabulary. So if we go down this route, I guess we'd have to redefine VARIABLE etc too to allocate data space inside this buffer. We still want to tick colon definitions and use EXECUTE and DEFER etc. Handling all of this right doesn't seem easy to me. But certainly an interesting challenge! (Maybe an opportunity to write a semi-useful library instead of tinkering with a useless toy Forth?)
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-25 13:18 +0100 |
| Subject | Emulating a 16-bit Forth |
| Message-ID | <86k2p6uval.fsf_-_@vps34351.public.cloudvps.com> |
| In reply to | #43705 |
>>>>> 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. >>>> >>>> Item 2 [a 16-bit Forth] is easy to do with a new vocabulary or word >>>> list. >>> >>> How would you easily implement @ in this vocabulary? >> >> If we are emulating a 16 bit CPU, then declare a 64k buffer and index >> into it. To allow for 16 bit access, assume that the 32 bit host has >> a word W@ ( addr -- x16 ). >> >> 64 kb buffer: vmem >> >> ... >> >> : @ ( addr16 -- x16 ) >> $FFFF and vmem + w@ >> ; > > The purpuse was to emulate a 16-bit Forth with a new vocabulary. So > if we go down this route, I guess we'd have to redefine VARIABLE etc > too to allocate data space inside this buffer. > > We still want to tick colon definitions and use EXECUTE and DEFER etc. So maybe something like this? It's kind of like a cross compiler for a 16-bit target, except the code lives in the host. only forth definitions vocabulary forth16 65536 constant #data create data #data allot variable dp 0 dp ! : mask 65535 and ; : ?addr dup -65536 and abort" Not a 16-bit address!" ; : >host ?addr data + ; : mask: >in @ >r : r> >in ! ' compile, postpone mask postpone ; ; : h: : ; : h; postpone ; ; immediate also forth16 definitions \ Add lots of these... mask: + mask: - mask: * mask: / : here dp @ ; : allot dp +! ; : execute >host @ execute ; : does does> @ execute ; : : create here dup , 1 cells allot does :noname ; h: ; postpone ; swap >host ! ; immediate h: create create here , does> @ h; h: variable create 2 allot h; h: ' ' >body @ h; h: >body h; h: c@ >host c@ h; h: c! >host c! h; \ Little endian versions. h: @ dup c@ swap 1+ c@ 8 lshift + h; h: ! 2dup c! swap 8 rshift swap 1+ c! h; h: c, here c! 1 allot h; h: , here ! 2 allot ; only forth definitions
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-11-25 14:08 +0100 |
| Subject | Re: Emulating a 16-bit Forth |
| Message-ID | <86d1uyuszv.fsf@vps34351.public.cloudvps.com> |
| In reply to | #43752 |
Lars Brinkhoff wrote: > h: create create here , does> @ h; Add this to support DOES> in the emulator. An actual use case for using multiple DOES> on the same defintion. h: does> postpone does> postpone @ h; immediate
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-09 14:30 +0000 |
| Message-ID | <5640aded$0$23765$e4fe514c@news.xs4all.nl> |
| In reply to | #43402 |
Paul Rubin <no.email@nospam.invalid> writes: >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). The generic system of ciforth is flexible enough to do that. It can generate a Linux Forth (32/64) and it can generate a 16 bit MSDOS. Carefully mix and match some macro files and you're there. If you specify AX the assembler will generate the appropriate address and operand length overrules. There is some attention needed while interfacing the OS, that expects 32 bits. > 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. This sounds like the most practical approach, with very few problems to be expected. E.g. a 32 bit roll would be isolated in a system-dependant section to later be recoded. >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. I doubt it. 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 | Bernd Linsel <bl1@gmx.com> |
|---|---|
| Date | 2015-11-09 18:27 +0100 |
| Message-ID | <n1ql0o$nh9$1@newsreader4.netcologne.de> |
| In reply to | #43402 |
On 11/9/2015 6: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. > Ever thought of using a MSP430 simulator on a PC, installing Mecrisp on that and use all the comfortable debugging tools available? This is one (commercial, but free for evaluation purposes) example: http://www.lauterbach.com/frames.html?dwnload.html Regards, -- Bernd
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-11-10 00:50 -0800 |
| Message-ID | <87si4es0en.fsf@nightsong.com> |
| In reply to | #43436 |
Bernd Linsel <bl1@gmx.com> writes: > Ever thought of using a MSP430 simulator on a PC, installing Mecrisp > on that and use all the comfortable debugging tools available? I considered the idea but hadn't gotten around to checking what emulators are available, and also didn't realize Mecrisp had good debugging features. Thanks for bringing it up as I should look into it more. > This is one (commercial, but free for evaluation purposes) example: > http://www.lauterbach.com/frames.html?dwnload.html I'd want to stay all FOSS, but thanks for the link. I know there are some AVR and other emulators around so maybe I could try AmForth. Again though, this all gets kind of complicated. The approach of just writing 32-bit code for 16-bit cells now seems workable for this particular task, so that's the simplest "solve the problem you have" approach.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-07 23:52 -1000 |
| Message-ID | <hsCdnZzkmNr9hqLLnZ2dnUU7-fednZ2d@supernews.com> |
| In reply to | #43347 |
On 11/7/15 9:56 PM, 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. I'm ignoring for the moment that it would have to be 100000. 200000. D+. It may be necessary in an application, but not at the system level. If you're writing an application that needs to handle numbers that don't fit in 16 bits and you know you will need to run it on both 16-bit and 32-bit targets, you use double numbers. Simple. The cost on the 32-bit targets will be negligible. > 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. No, you don't. It should work just fine if you have avoided 2 + instead of CELL+ etc. I personally (and FORTH, Inc corporately) have ported tons of code from 16-bit to 32-bit systems. It's really easy. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-07 23:16 -1000 |
| Message-ID | <n7SdnfgdNuJHj6LLnZ2dnUU7-TmdnZ2d@supernews.com> |
| In reply to | #43336 |
On 11/7/15 1:03 PM, rickman wrote: > On 11/7/2015 5:25 PM, Paul Rubin wrote: >> rickman <gnuarm@gmail.com> writes: >>>> 1. Being written entirely in Forth with no external dependencies, >>>> instead of booting from assembler. >>>> >>>> 2. Being able to choose the cell size at build time, or maybe >>>> even >>>> run time. >>> I'm not at all clear on item 2. Can you explain that a bit more? How >>> would this be useful much less important? >> >> Say you have a Forth program that assumes a 32-bit cell size. It works >> great on x86 and ARM, but you'd like to run it on MSP430. So you build >> the MSP430 Forth for 32-bit cells. Or maybe you want to run a 16-bit >> program on an ARM. You get the idea. > > No, I don't really. What has to change to compile a forth for 16 bit > machine? Isn't a cell a cell? Unless you overflow the cell size in > some operation, a forth system is cell size agnostic I thought. What > operations will exceed the capacity of a 16 bit cell. If you have respected the use of CELLS, etc., in your development, very little needs to change. If you really want to write code that is portable across 16 & 32-bit systems you need to make a few things doubles (even on the 32-bit platforms) instead of singles, but that's not a big deal. >>> I also don't see how you can achieve item 1 if you are going to >>> support multiple CPUs. Can you explain that? >> >> The primitives are written in an embedded Forth assembler for the cpus >> in question. That is very traditional. I didn't mean there's no >> assembly code, but just that you start from Forth instead of an external >> assembler. > > Ok, so rather than use a FOSS assembler, you feel the need to write your > own and to support that you want to code in Forthish assembly > language... which still is not portable across CPUs. Hmmm... I ask, > what is the value in this? I'm not seeing it. Tradition is not always > optimal. The value is that the target-specific sections are well-defined, few in number, and readily manageable. There's a huge value in having everything under your control. We can get SwiftX up on a totally new processor in a few weeks; thereafter, it's days at most to deal with a new target board. At the system level, nothing is going to be effortlessly portable, because there are intrinsic differences in targets. It may be possible to write something that would be more portable, but the loss in runtime efficiency would make it unusable for significant applications, IMO. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-11-07 23:07 -1000 |
| Message-ID | <leednbLMO48qjaLLnZ2dnUU7-TOdnZ2d@supernews.com> |
| In reply to | #43331 |
On 11/7/15 12:25 PM, Paul Rubin wrote: > rickman <gnuarm@gmail.com> writes: >>> 1. Being written entirely in Forth with no external dependencies, >>> instead of booting from assembler. >>> >>> 2. Being able to choose the cell size at build time, or maybe even >>> run time. >> I'm not at all clear on item 2. Can you explain that a bit more? How >> would this be useful much less important? > > Say you have a Forth program that assumes a 32-bit cell size. It works > great on x86 and ARM, but you'd like to run it on MSP430. So you build > the MSP430 Forth for 32-bit cells. Or maybe you want to run a 16-bit > program on an ARM. You get the idea. SwiftX (FORTH, Inc.'s line of fully interactive cross-compilers for embedded microcontrollers) supports at any one time ~a dozen different processors, 8 & 16-bit (both of which we support with a 16-bit implementation) and 32-bit. Each processor requires about 20 files of platform-specific code, including its assembler and optimizing compiler and hardware support. The rest of the system (including most high-level functions, host communications, utilities, libraries, etc.) comprise nearly 70 files that are *fully compatible* across the entire product line. >> I also don't see how you can achieve item 1 if you are going to >> support multiple CPUs. Can you explain that? > > The primitives are written in an embedded Forth assembler for the cpus > in question. That is very traditional. I didn't mean there's no > assembly code, but just that you start from Forth instead of an external > assembler. There is no external support required, but the ~20 files I mentioned above support full access to the target processor and the board it's on without leaving the SwiftX environment. 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 | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-11-08 17:58 +0000 |
| Message-ID | <563f8d2e$0$23800$e4fe514c@news.xs4all.nl> |
| In reply to | #43331 |
Paul Rubin <no.email@nospam.invalid> writes: >rickman <gnuarm@gmail.com> writes: >>> 1. Being written entirely in Forth with no external dependencies, >>> instead of booting from assembler. >>> >>> 2. Being able to choose the cell size at build time, or maybe even >>> run time. >> I'm not at all clear on item 2. Can you explain that a bit more? How >> would this be useful much less important? >Say you have a Forth program that assumes a 32-bit cell size. It works >great on x86 and ARM, but you'd like to run it on MSP430. So you build >the MSP430 Forth for 32-bit cells. Or maybe you want to run a 16-bit >program on an ARM. You get the idea. >> I also don't see how you can achieve item 1 if you are going to >> support multiple CPUs. Can you explain that? >The primitives are written in an embedded Forth assembler for the cpus >in question. That is very traditional. I didn't mean there's no >assembly code, but just that you start from Forth instead of an external >assembler. I'm sorry, but this remark betrays lack of practical experience with this. ciforth is written in assembler and I use FASM. The assembler/disassembler ciasdis is associated with ciforth, and I've demonstrated that I can replace FASM with that assembler. (I've a source for an old version 4.0.3 that can be assembled by ciasdis. Absolutely nothing needed, except for a previous version of ciforth). Only, that is a stupid idea and a waste of time. All assembler codes are equivalent, so I can just mechanically translate between FASM code and mine back and Forth. This exercise buys you two things: 1. the external world sees an unfamiliar rendering of the Intel opcodes and operands 2. you have to dive into the hassle of the ELF headers yourself. Groetjes Alebert -- 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]
Page 5 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