Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #19765 > unrolled thread
| Started by | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| First post | 2013-02-16 07:35 -0800 |
| Last post | 2013-03-15 21:13 -0700 |
| Articles | 20 on this page of 105 — 21 participants |
Back to article view | Back to comp.lang.forth
Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-16 07:35 -0800
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-17 13:57 +0200
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-17 09:40 -0600
Re: Integer cosine function "Elizabeth D. Rather" <erather@forth.com> - 2013-02-17 07:51 -1000
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-17 19:06 +0200
Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-18 14:46 +0000
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-19 20:01 +0100
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-02-19 21:34 +0200
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-19 21:46 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-19 15:55 -0800
Re: Integer cosine function Coos Haak <chforth@hccnet.nl> - 2013-02-21 00:59 +0100
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-18 09:19 -0800
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-18 14:27 -0500
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-18 20:53 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-18 19:10 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-19 13:13 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-19 23:04 -0500
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-20 10:00 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-21 13:04 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-21 19:03 -0500
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 02:45 +0100
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-22 02:32 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 16:01 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 22:07 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 10:27 -0500
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 03:59 -0600
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-02-22 02:30 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 15:56 +0100
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-22 16:13 +0100
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 17:45 +0100
Re: Integer cosine function Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2013-02-22 18:44 +0100
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 19:19 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 14:43 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-23 01:30 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 21:51 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-24 01:43 +0100
Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-25 17:55 +0000
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-25 21:01 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-25 23:22 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-26 15:11 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-27 08:05 -0500
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 22:14 -0500
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-27 22:56 -0500
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:37 -0500
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-03-07 13:12 -0500
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-28 08:00 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:38 -0500
Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-02-28 16:55 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:38 -0500
Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-04 11:08 +0000
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-04 03:39 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:49 -0500
Re: Integer cosine function stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-05 10:20 +0000
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 00:12 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-08 04:21 -0500
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:50 -0500
Re: Integer cosine function Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-03-05 07:16 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:56 -0500
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 00:24 -0800
Re: Integer cosine function Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-07 07:34 -0800
Re: Integer cosine function Lars Brinkhoff <lars.spam@nocrew.org> - 2013-02-28 12:57 +0100
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-28 17:07 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-28 19:37 -0800
Re: Integer cosine function stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-01 10:56 +0000
Re: Integer cosine function anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-01 13:52 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 17:48 -0800
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-03-13 17:44 -0400
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 21:36 -0500
Re: Integer cosine function Elizabeth D Rather <erather@forth.com> - 2013-03-01 19:14 -1000
Re: Integer cosine function mhx@iae.nl (Marcel Hendrix) - 2013-03-02 09:34 +0200
Re: Integer cosine function kenney@cix.compulink.co.uk - 2013-03-02 09:06 -0600
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-26 08:53 -0800
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-26 16:59 -0500
Re: Integer cosine function albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-27 00:52 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-27 04:07 -0500
Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-05 20:51 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 17:58 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-06 16:39 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 14:21 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 00:11 +0100
Re: Integer cosine function albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-06 23:44 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 16:24 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 01:59 +0100
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-06 19:48 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-07 16:22 +0100
Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-06 23:37 +0000
Re: Integer cosine function "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-23 09:54 -0500
Re: Integer cosine function "WJ" <w_a_x_man@yahoo.com> - 2013-03-05 21:03 +0000
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 15:59 -0800
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-03-05 16:38 -0800
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-22 12:07 -0600
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-22 19:39 +0100
Re: Integer cosine function "Elizabeth D. Rather" <erather@forth.com> - 2013-02-22 09:23 -1000
Re: Integer cosine function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-23 04:44 -0600
Re: Integer cosine function Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-22 13:00 -0800
Re: Integer cosine function Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-23 01:09 +0100
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-22 21:16 -0500
Re: Integer cosine function rickman <gnuarm@gmail.com> - 2013-02-22 20:28 -0500
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-27 07:59 -0800
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-02-27 08:48 -0800
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-02-27 10:23 -0800
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-03-15 10:14 -0700
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-03-15 13:19 -0700
Re: Integer cosine function Brad Eckert <hwfwguy@gmail.com> - 2013-03-15 13:28 -0700
Re: Integer cosine function Gary Bergstrom <g.bergstrom@ieee.org> - 2013-03-15 21:13 -0700
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-03-06 23:44 +0000 |
| Message-ID | <5137d4d2$0$617$e4fe514c@dreader34.news.xs4all.nl> |
| In reply to | #20368 |
In article <kh8ife$inb$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Hugh Aguilar wrote: >> Nowadays Anton Ertl refers to >> Gforth as the "mainstream system," but I'm not aware of anybody having >> ever written a commercial product in Gforth --- so I think the score >> is 1 to 0 in my favor. :-) > >Well, a lot of people use Gforth. We rarely hear what they do with it. I >can assure you that people use Gforth not only for hobbyist work, but also >for commercial work, in so far as the GPL permits (which is quite a lot, >since most Forth programs are in-house usage, and no source code has to go >outside). > >Not every development gets out to customers. Two friends of mine in Munich >ported Gforth EC once to Siemens' latest smart card processor, which didn't >have a really working C compiler at that time. The port was a success, they >had played Tetris for terminals on the processor while the C people still >were struggling with Hello World. But in fact, this didn't help the >smartcard processor from Siemens, which never became a commercial product. >People rather use these 8051-based smartcards... > >> The clever trick with ISYS, which I borrowed for my Forth, was to have >> a split parameter-stack. Most Forths have a parameter stack with the >> high and low bytes of each cell adjacent to each other. Assuming that >> the stack-pointer is X, then two INX instructions are needed to drop a >> cell from the stack, and two DEX instructions are needed to make room >> for a cell on the stack. With the split stack however, the low bytes >> of the cells are in one stack and the high bytes of the cells are in >> another stack, and the two stacks are $40 bytes apart. You use a >> different base address ($0 for the low bytes and $40 for the high >> bytes) to get the low or high byte of the value. The clever part here >> is that only one INX instruction is needed to drop a cell from the >> stack, and only one DEX instruction is needed to make room for a cell >> on the stack. > >Nice trick, indeed. However, you can't access the stack through sp@ + @. > >> All in all, the 6502 and its derivatives (the 65c02 in the Apple and >> the 6510 in the C64) was a pretty cool processor. > >A lot of people got first contact with computers having that processor in >it. > >> The indirect,X addressing mode was a big waste. It was almost never >> used by anybody. All of those instructions should have been something >> more useful. For the most part though, the 6502 was a good design --- >> it was way better than the 6800 that preceded it --- it offered more >> opportunity for writing small tight code than the Z80, although the >> Z80 was easier to program by most accounts. The 6809 was better than >> both, but it only got used in the Radio Shack Color Computer for home >> use, and in various OS9 computers for industrial use --- if Motorola >> would have stuck with it, they could have succeeded --- but Motorola >> repeatedly introduced new-and-improved processors and forced their >> customers to rewrite their programs, which is why everybody just >> switched over to the Intel 8051 even though it was hard to program by >> most standards. > >I've said that the 8051 is what people who stick to what they have done for >the last 30 years like. Motorola quickly went from the 6809 to the 68HC11, >and *that one* lasted. It is AFAIK still in production, even from the >original vendor (which is now called Freescale), though it's of course a >legacy product. It is available as synthesizable core, for today's typical >deeply embedded silicon stuff. We have heard that remark from Hugh before. It is false. I had a job recently to convert 6805 (as old as the 8051) assembly language, because the chips were End Of life after 20 years and had to be replaced. The code now runs on the latest 68 controllers. I could salvage all regular assembler code unaltered, and with some macro trickery (mostly to do with addresses) the peripheral control code. Note that the 20+ year code was translated using the newest Eclipse Freescale tools. So much for Motorola/Freescale leaving their customers in the cold. > >-- >Bernd Paysan 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 | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-03-06 16:24 -0800 |
| Message-ID | <55cc0992-3d0e-47ab-8b78-303f3d4a3e84@w2g2000pbw.googlegroups.com> |
| In reply to | #20368 |
On Mar 6, 4:11 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > Hugh Aguilar wrote: > > The clever trick with ISYS, which I borrowed for my Forth, was to have > > a split parameter-stack. Most Forths have a parameter stack with the > > high and low bytes of each cell adjacent to each other. Assuming that > > the stack-pointer is X, then two INX instructions are needed to drop a > > cell from the stack, and two DEX instructions are needed to make room > > for a cell on the stack. With the split stack however, the low bytes > > of the cells are in one stack and the high bytes of the cells are in > > another stack, and the two stacks are $40 bytes apart. You use a > > different base address ($0 for the low bytes and $40 for the high > > bytes) to get the low or high byte of the value. The clever part here > > is that only one INX instruction is needed to drop a cell from the > > stack, and only one DEX instruction is needed to make room for a cell > > on the stack. > > Nice trick, indeed. However, you can't access the stack through sp@ + @. I had to read that sentence about three times before I figured out what you were talking about. That is a really obscure coding practice --- I've never done that, and I can't think of any case in which I would want to. The big weakness I found in the 6502, was that there was no indirect addressing into the return stack. The designers should have provided an index,S addressing mode, rather than the indirect,X addressing mode. WDC did do this on the 65c816 --- that thing was specifically designed to support the C stack-frame --- it wasn't a very good target for Forth though. > I've said that the 8051 is what people who stick to what they have done for > the last 30 years like. Motorola quickly went from the 6809 to the 68HC11, > and *that one* lasted. It is AFAIK still in production, even from the > original vendor (which is now called Freescale), though it's of course a > legacy product. It is available as synthesizable core, for today's typical > deeply embedded silicon stuff. FreeScale is here in Phoenix (actually it is Chandler and Tempe, over in that side of the valley). Those processors seem to be not very popular anymore --- I think they mostly just support legacy stuff, and aren't used very much for new projects. Slava once told me that the ColdFire was the smallest processor that he expected Factor could support. All of those processors are pretty good targets for Forth though.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-03-07 01:59 +0100 |
| Message-ID | <kh8op0$mf7$1@online.de> |
| In reply to | #20377 |
Hugh Aguilar wrote: > On Mar 6, 4:11 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: >> Nice trick, indeed. However, you can't access the stack through sp@ + @. > > I had to read that sentence about three times before I figured out > what you were talking about. That is a really obscure coding practice > --- I've never done that, and I can't think of any case in which I > would want to. Multitasker, set up the stack before you jump into the task. Or to write PICK or some other obsure stack manipulation words you rarely use in high level at the start of the porting effort (Gforth EC does that for you). > FreeScale is here in Phoenix (actually it is Chandler and Tempe, over > in that side of the valley). > > Those processors seem to be not very popular anymore --- I think they > mostly just support legacy stuff, and aren't used very much for new > projects. Yes. The people who stick to legacy forever aren't Freescale's customers, those all use the 8051. > Slava once told me that the ColdFire was the smallest processor that > he expected Factor could support. All of those processors are pretty > good targets for Forth though. The step from the 8 bit processors to the 68k (and ColdFire is just a simpler version of the 68k) was a quantum leap. From a Forth point of view, the 8051 is pretty close to a "non-Forth-Processor", the smaller PICs definitely are non-Forth processors, you just can't do it. The 68k is a very nice processor to implement Forth efficiently on. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-03-06 19:48 -0800 |
| Message-ID | <9de9b3a5-fe9a-48d2-b1dd-3e1cf8329e24@oz4g2000pbc.googlegroups.com> |
| In reply to | #20378 |
On Mar 6, 5:59 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > From a Forth point of view, > the 8051 is pretty close to a "non-Forth-Processor", the smaller PICs > definitely are non-Forth processors, you just can't do it. Well, there is this: http://zwizwa.be/staapl/ It is possible to write a Forth for the 8051 or the PIC18 --- but it would be painful --- I would have to be pretty inspired ($$$) to attempt it. > The 68k is a > very nice processor to implement Forth efficiently on. I thought it was a cool processor, but I've never programmed for it, so I don't have any direct experience. I read that it was possible to make variations of the 68K by modifying the micro-code --- and that somebody once did this to make a Forth- centric 68K --- I suppose they made NEXT a single instruction, but I don't really know. I think there are FPGA versions of the 68K now, so the idea is more realistic now.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-03-07 16:22 +0100 |
| Message-ID | <khabce$36i$1@online.de> |
| In reply to | #20382 |
Hugh Aguilar wrote: > On Mar 6, 5:59 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: >> From a Forth point of view, >> the 8051 is pretty close to a "non-Forth-Processor", the smaller PICs >> definitely are non-Forth processors, you just can't do it. > > Well, there is this: http://zwizwa.be/staapl/ The PIC18 is the last and largest of the PIC1x series. > It is possible to write a Forth for the 8051 or the PIC18 --- but it > would be painful --- I would have to be pretty inspired ($$$) to > attempt it. There are even people who try it on PIC12 and PIC16: http://sourceforge.net/projects/picoforth-alpha/ It's a cross compiler, though (written in Gforth), and it compiles to assembler, not some threaded code. It is next to impossbile to make threaded code on PIC16 and smaller, because you can't properly access the ROM (retlw xx tables are the only way). >> The 68k is a >> very nice processor to implement Forth efficiently on. > > I thought it was a cool processor, but I've never programmed for it, > so I don't have any direct experience. I wrote my first Forth (bigForth) on it. > I read that it was possible to make variations of the 68K by modifying > the micro-code --- and that somebody once did this to make a Forth- > centric 68K --- I suppose they made NEXT a single instruction, but I > don't really know. I think there are FPGA versions of the 68K now, so > the idea is more realistic now. You better make a native code Forth on 68k, with macro-copying and peephole optimization; many primitives are just one or two instructions. The optimizer in bigForth is just 4 screens, and the peephole table is another 16. If you want to make a Forth processor in an FPGA, just make a Forth processor. No need to add all the complex stuff the 68k had. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2013-03-06 23:37 +0000 |
| Message-ID | <kh8k07$tnj$1@dont-email.me> |
| In reply to | #20362 |
Hugh Aguilar wrote: > the 6502 was a good design --- > it was way better than the 6800 that preceded it --- it offered more > opportunity for writing small tight code than the Z80, although the > Z80 was easier to program by most accounts. The 6809 was better than > both, but it only got used in the Radio Shack Color Computer for home > use, and in various OS9 computers for industrial use --- I did a very modest amount of assembly language programming for both of those chips. One big advantage that the 6809 had was a multiply instruction.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2013-02-23 09:54 -0500 |
| Message-ID | <kgal3t$bes$1@speranza.aioe.org> |
| In reply to | #19929 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:55e44f69-28e2-41ee-8248-4f0bd54b114a@l13g2000yqe.googlegroups.com... > Also, memory was extremely tight in the old days. The 8051 > [has] a very clever memory system that allowed significantly > more that 256 cells to be addressed, while still using only > 8-bit registers. > Well, being unfamiliar with the 8051, I thought you maybe were confusing it with the 6502. The 6502 has zero-page addessing. However, it seems the 8051 has a similar addressing mode. From my recollection of a bunch of other micro's of the era, I thought the 6502 was the only one. So, I'm quite shocked that more than one micro had that feature! So, I guess were even. I just learned something from you... ;-) Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2013-03-05 21:03 +0000 |
| Message-ID | <kh5mil$4ee$1@dont-email.me> |
| In reply to | #19929 |
Hugh Aguilar wrote: > --- GForth is truly crap, as it runs about an order of magnitude too > slow for any serious application --- It seems pretty fast to me. I seem to recall that a few years ago the Factor folk were trying to equal the speed of GForth (not to mention gforth-fast). You may not realize it, but processors in personal computers are much faster than they used to be. People used to run "serious applications" on Macintoshes and Amigas equipped with MC68000 processors. Now those applications can be written in languages that are not as fast as C. However, GForth and other ANS Forths are low-level languages; it's much easier to program applications in a high-level language.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-03-05 15:59 -0800 |
| Message-ID | <8fcafbf4-699c-4db3-a691-bc5faf5904e4@q8g2000pbn.googlegroups.com> |
| In reply to | #20319 |
On Mar 5, 2:03 pm, "WJ" <w_a_x_...@yahoo.com> wrote: > Hugh Aguilar wrote: > > --- GForth is truly crap, as it runs about an order of magnitude too > > slow for any serious application --- > > It seems pretty fast to me. I seem to recall that a few years > ago the Factor folk were trying to equal the speed of GForth > (not to mention gforth-fast). > > You may not realize it, but processors in personal computers > are much faster than they used to be. People used to run > "serious applications" on Macintoshes and Amigas equipped with > MC68000 processors. Now those applications can be written in > languages that are not as fast as C. > > However, GForth and other ANS Forths are low-level languages; > it's much easier to program applications in a high-level language. I don't mean the term "toy interpreter" in an entirely disparaging way. What you said was true: "Lua, Python, Ruby, etc., ... have done a lot more data processing than Forth has." All of these, and Factor too, are Scheme derivatives. All of them have dynamic OOP. It is "much easier" to program applications in these rather than in a low-level language --- but only if your application can be limited to the handful of data types that dynamic-OOP supports. In dynamic-OOP, every datum has a tag. In Scheme this is 2 bits, so there are 4 (2^2) possible data types. In Lua the tag is 3 bits, so there are 16 (2^3) possible data types. Every function, such as + or whatever, has to jump through a table at run-time depending upon the values in the tags of the datums that it is given as parameters. If there are 4 data types, then there are 16 (4x4) entries in the table. If there are 8 data types, then there are 64 (8x8) entries in the table. That is how many permutations the two datums can have. In some cases it is half that because the data can be in either order (plus and times for example), but in other cases it is the full table because the data's order matters (minus and divide, for example). In any case, this is really complicated and time-consuming code. There is a lot of work being done at run-time just to add two datums together, which in a low-level language would typically optimize down to one or two machine instructions (for integers or floats, although more than that for strings or whatever). Most of these languages speed things up somewhat by allowing the programmer to declare the type of a datum at compile-time. This, of course, makes me wonder why not just use a static language in the first place? Even with this half-step toward being static however, the dynamic-OOP languages are limited in how many data types they can support, which allows them to be used as a purely dynamic-OOP language without any declarations. Dynamic-OOP languages are a Procrustean Bed. So long as your application can be limited to the handful of data types provided, then they are super-convenient. If your application needs any other data type however, then you get your feet chopped off at the ankles to make you fit in the bed --- there is no way to extend the language with new data types. Maybe Gforth "seems pretty fast" to you, but that is as compared to Factor, which is a dynamic-OOP language. Dynamic-OOP languages are inherently slow. Only with a lot of work can they be made to run fast, and they have to become quasi-static languages in the process. The fact that Factor is now faster than Gforth, indicates these things: 1.) A lot of work has been done to make Factor fast, whereas the Gforth crowd has gotten bogged down in their overly-complicated badly- designed compiler. 2.) Factor compiles into machine-code, whereas Gforth compiles into C, so Factor has an inherent advantage. Factor is actually one of the best dynamic-OOP languages around. Almost all dynamic-OOP languages lack mixed-precision arithmetic. For example, Racket has only 4 data types, and one of them is the 30-bit integer --- there is no double-precision integer. Even if there was a double-precision integer it would be very complicated to implement mixed-precision arithmetic because there is no clear way for the programmer to indicate whether the result should be single or double given two single-precision parameters. Slava did implement some kind of mixed-precision arithmetic though --- he did that in response to seeing my LC53 program, which was significantly faster in Forth than in Factor because it relied on mixed-precision arithmetic whereas Factor upgraded everything to double-precision. I quit programming in Factor shortly after that time, so I don't know how far Slava went with the mixed-precision idea. The fact that Slava was making any effort at all to provide mixed-precision arithmetic was pretty amazing though --- over on the Racket mailing list I brought up the subject of mixed-precision arithmetic, and complained that Racket's 30-bit integer wasn't very useful, and I was told that people who know anything about numerical programming (not me), just use floating-point for everything. That was pretty unimpressive! Anyway, dynamic-OOP is the anti-thesis of Forth. The Forth proverb is: "Let the dictionary do the deciding." In CAMForth I will support several data types. There is no limit (4 or 8, depending upon tag size) to how many data types I can support --- the only limit is in how much time I want to invest in writing the compiler. For example, strings are a data type. This means that the language will define various string functions, such a concatenation, as part of the language. Because these are part of the language, they can be written in assembly-language. In ANS-Forth and Forth-200x, these are not defined as part of the language, and hence they have to be written in high-level Forth. This is largely why I feel confident that CAMForth will be 10x faster than Gforth. I define a lot of functions related to numbers and strings as part of the language, which allows me to write that stuff in assembly-language. By comparison, in ANS-Forth, this stuff has to be written in high-level Forth, and even with the best optimizer it is going to come out a lot slower than hand-written assembly-language. Also, I define structs (FIELD) as part of the language, as well as arrays and lists, so any program that uses any kind of data structure should be significantly faster in CAMForth than in ANS-Forth, as ANS-Forth requires all of this low-level code to be implemented in high-level Forth --- if it were part of the language, then it could be implemented in assembly- language without breaking standard-compliance, but it isn't.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-03-05 16:38 -0800 |
| Message-ID | <75b9cfe7-4541-44b1-8dd5-0efabc9fed8c@hd10g2000pbc.googlegroups.com> |
| In reply to | #20324 |
On Mar 5, 4:59 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > In dynamic-OOP, every datum has a tag. In Scheme this is 2 bits, so > there are 4 (2^2) possible data types. In Lua the tag is 3 bits, so > there are 16 (2^3) possible data types. I meant 8 (2^3) possible data types.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-22 12:07 -0600 |
| Message-ID | <QM2dnWw1Z_ZxLrrMnZ2dnUVZ_gadnZ2d@supernews.com> |
| In reply to | #19907 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >> You need to point that arrow of reasoning back at yourself, though: >> you don't like the 8051, so you consider people who choose it to be >> irrational! > > I've had no exposure to the 8051 before that project, I was > completely agnostic at that point of time. I started to hate it > when I saw what kind of crap it was. The b16 came into existence as > I was motivated to do something better, and it took me only *days* > to do so. I struggled about half a year with the various IPs from > Inventra (8051, debugger, USB, and writing test code in 8051 > assembler), only to glue them together. > > I've ported Gforth to a competitor of the 8051, the R8C, it took a > week to get Gforth up and running. It is a nice CPU. I also like > the msp430. There are nice CPUs in the 8051 ballpark out there, and > there is crapware like the 8051, and it *does* impact my > productivity. After I'm slowed down for enough time, I start to get > emotional. > >> The truth is that all of us make decisions for emotional >> reasons and save our intellectual firepower to construct elaborate >> rationalizations to justify them. > > Yes, after struggling half a year with utter crap, I have emotional > reasons. It wouldn't have taken half a year it it wasn't crap. > Part of the crappy feeling of course was the Inventra > implementation, which looked like some beginner from India wrote it > (it couldn't talk to synchronos SRAM, and all the SRAM blocks you > can compile are synchronous, because synchronous is the right way to > do it), the other part of the "this is crap" feeling came from > writing test code in assembler. This CPU is certainly not the best > of breed. And I have seen many CPUs. > > And then I talked to the consultant who wrote a significant part of > the firmware. She complained about the crappy Keil compiler, the > half-working debugger, and that there are better CPUs out there... > And of course, we were accused of producing crap, too. Because the > debugger had some flaws, which we did somehow overcome at our side, > but the people who used it together with the Keil didn't, and > finally, they got some support from the subcontractors who made the > debugger for Inventra (it was all outsourced, Inventra did nothing > themselves)... because the Keil interface to that debugger really > didn't work. But this is just a rant. The 8051 is a perfectly decent little microcontroller. It's not very fast, and it doesn't have very much memory, but if it is fast enough and big enough for what you need to do, it's fine. Of course it can be implemented badly, and bad tools exist, but you don't have to use them. There's nothing about the 8051 that should extend development time, as long as you have decent tools. I am, of course, assuming that if you're going to compare two processors, you have a equally good Forth implementation on both of them. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-22 19:39 +0100 |
| Message-ID | <kg8e0c$22g$1@online.de> |
| In reply to | #19920 |
Andrew Haley wrote: > But this is just a rant. The 8051 is a perfectly decent little > microcontroller. It's not very fast, and it doesn't have very much > memory, but if it is fast enough and big enough for what you need to > do, it's fine. Of course it can be implemented badly, and bad tools > exist, but you don't have to use them. No, I had to use them, both the bad implementation and the bad tools. It was part of the decision made by the customer. I have not seen any 8051 together with usable tools and a clean, easy to instantiate implementation. > There's nothing about the 8051 > that should extend development time, as long as you have decent tools. That 8051 core was from a highly recognized silicon valley brand name for IP design. The other implementations, as our customer concluded, must be much worse; though we had suggested them to use a core made in Poland, which did cost one 10th of the money, and looked quite promising. I know that paying a lot of money does not mean high quality, but this Inventra core *is* the best selling SoC core for 8051s. It really is the best thing you can buy, accorind to the herd. And the debugger and Keil C compiler are the best tools money can buy. Really, believe me. My customers believed it religiously, so it must be true. It turned out that we were the first customer to use that debugger on an 8051, nobody else has bought it before in that configuration. > I am, of course, assuming that if you're going to compare two > processors, you have a equally good Forth implementation on both of > them. I really didn't want to waste the time to port Gforth to that crap, especially since the customer didn't let us do any software development apart from the test programs, which were rather small. To be honest: These devices are originally too small to host a real Forth, and you should really stick to that original code size - anything more than 4k of code on an 8051 is too much, it's not designed for that. And then, you should code them in their assembler, not in a HLL. The concepts they use to make the code compact are not easy to use from a HLL. For implementing a Forth, my conclusion is that the 8051 doesn't have enough pointers to make that easy to do, so you code becomes pretty bloated. Compare that to an msp430 or the r8c. It's really worlds apart. The constraint that neither msp430 nor r8c are of the same time doesn't apply when the decision is made now (or 10 years ago). I'm not arguing that using an 8051 in the 80s is a wrong decision. But being stuck in the 80s forever is wrong. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2013-02-22 09:23 -1000 |
| Message-ID | <NfCdnbxNRpsvWLrMnZ2dnUVZ_qadnZ2d@supernews.com> |
| In reply to | #19923 |
On 2/22/13 8:39 AM, Bernd Paysan wrote: ... > To be honest: These devices are originally too small to host a real Forth, > and you should really stick to that original code size - anything more than > 4k of code on an 8051 is too much, it's not designed for that. And then, > you should code them in their assembler, not in a HLL. The concepts they > use to make the code compact are not easy to use from a HLL. > > For implementing a Forth, my conclusion is that the 8051 doesn't have enough > pointers to make that easy to do, so you code becomes pretty bloated. > Compare that to an msp430 or the r8c. It's really worlds apart. The > constraint that neither msp430 nor r8c are of the same time doesn't apply > when the decision is made now (or 10 years ago). I'm not arguing that using > an 8051 in the 80s is a wrong decision. But being stuck in the 80s forever > is wrong. > The 8051's main appeal is that it's incredibly cheap in quantity, so designers looking for low unit costs like it. And the multitude of configurations is attractive, too. In my experience these decisions are usually made by the hardware guys who don't have to write the code. We have done many, many projects on 8051s, pretty much since it came out. However, we've always supported it with cross-compilers, as we agree that it isn't a hospitable target for a resident Forth. Although I think everyone agrees that the Keil C compiler is superb, SwiftX generates pretty good code for 8051s, and the modularity of Forth (which makes for very small programs compared with C) plus interactive development style and the inclusion of an efficient multitasker has kept it as a popular choice for our customers. 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-02-23 04:44 -0600 |
| Message-ID | <YL2dnTi896PtALXMnZ2dnUVZ_radnZ2d@supernews.com> |
| In reply to | #19923 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > To be honest: These devices are originally too small to host a real > Forth, And speaking as someone who has has ported a real Forth to the 8051, to be honest: that opinion is nonsense. > and you should really stick to that original code size - anything > more than 4k of code on an 8051 is too much, it's not designed for > that. And then, you should code them in their assembler, not in a > HLL. The concepts they use to make the code compact are not easy to > use from a HLL. > > For implementing a Forth, my conclusion is that the 8051 doesn't > have enough pointers to make that easy to do, so you code becomes > pretty bloated. Eh? Enough pointers? All the architecture of the 8051 does is mean that the Forth doesn't run very fast. But an embedded computer olny has to be fast enough. IME, Forth code on the 8051 can be extremely small, with byte token-threading. > Compare that to an msp430 or the r8c. It's really worlds apart. > The constraint that neither msp430 nor r8c are of the same time > doesn't apply when the decision is made now (or 10 years ago). I'm > not arguing that using an 8051 in the 80s is a wrong decision. But > being stuck in the 80s forever is wrong. Could be. But that doesn't make it crap. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-02-22 13:00 -0800 |
| Message-ID | <36a1d596-517b-444b-bce3-da5af7e92829@f6g2000yqm.googlegroups.com> |
| In reply to | #19907 |
On Feb 22, 7:56 am, Bernd Paysan <bernd.pay...@gmx.de> wrote: > Andrew Haley wrote: > > You need to point that arrow of reasoning back at yourself, though: > > you don't like the 8051, so you consider people who choose it to be > > irrational! > > I've had no exposure to the 8051 before that project, I was completely > agnostic at that point of time. I started to hate it when I saw what kind > of crap it was. The b16 came into existence as I was motivated to do > something better, and it took me only *days* to do so. Where is any employer going to somebody to program the B16? C.L.F.? LOL Companies use standard chips such as the 8051 so they can post a help- wanted ad for a programmer on Friday, requiring 3+ years experience, and get hundreds of applicants on Monday --- many of the applicants will be homeless people, so the employer doesn't have to bother with paying them enough to make the rent --- if any of them have a bad attitude (you seem to be pretty full of yourself: which is what I'm referring to), they can give him the bum's rush and have another warm body in his chair the next morning.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-02-23 01:09 +0100 |
| Message-ID | <kg91c0$fha$1@online.de> |
| In reply to | #19928 |
Hugh Aguilar wrote: > On Feb 22, 7:56 am, Bernd Paysan <bernd.pay...@gmx.de> wrote: >> I've had no exposure to the 8051 before that project, I was completely >> agnostic at that point of time. I started to hate it when I saw what >> kind of crap it was. The b16 came into existence as I was motivated to >> do something better, and it took me only *days* to do so. > > Where is any employer going to somebody to program the B16? C.L.F.? > LOL Hey, we did four projects with the b16. About half of the projects we did after I made the b16 had one inside. The last one was going into some iPods, as battery monitor. The employer had some mental problems with the b16, but the ARM was 10 times more expensive (and this ARM Cortex M0 is about as cheap as an 8051!). That simply didn't fit into the budget. The total costs Apple was willing to spend on a battery monitor was about 30 cents. Apart from myself, we recruited the programmers from the team. They had to learn Forth. The second boss who tried this probably wanted to prove that this is impossible - my coworker struggled with Forth for a month to complete what I would have done in a few days. But then, he was hooked. I'm not sure if this was the result my boss was hoping for. > Companies use standard chips such as the 8051 so they can post a help- > wanted ad for a programmer on Friday, requiring 3+ years experience, > and get hundreds of applicants on Monday --- many of the applicants > will be homeless people, so the employer doesn't have to bother with > paying them enough to make the rent Haha. Maybe in India. Or whatever third world country you live in at the moment. My advice: Get out. You don't have to stay where there are no jobs, better move elsewhere. Especially if you don't have any home there. You can be homeless whereever you like. > --- if any of them have a bad > attitude (you seem to be pretty full of yourself: which is what I'm > referring to), they can give him the bum's rush and have another warm > body in his chair the next morning. That's what employers who are full of themselves like to have. Replacible dolts, best homeless and near starvation, so that they will do whatever you order them for food. Reality is different. Good employers value good people, and good people know that they are good. Bad employers don't like that, they say "you are full of yourself, we can't make use of people like that." Well, for a start, you have to pay more, not just money, but also respect. It pays off. I did earn quite a lot at the previous employers, and they also made a lot of money from my work. The project I liked best was the digital audio amplifier, and that chip was mostly designed by two real experts - me and a consultant, who was even more difficult to work with. According to the management, of course, I found him easy to work with, because he was smart. His brother is a manager for a software company, and he says, the top 5% engineers keep the company going, you have to treat them well, and everything is fine. You don't have to manage them, they know what to do, better than the manager. They are self-motivated by success. That last employer with Apple as customer was really funny, in the sense that Dilber comics are funny. They treated me and my team as alien right from start. It was always us vs. them for them, and of course, we were all strange people, who wrote *software* and stuff like that. Well, we would call it firmware, but for them, it was all that software thing. I soon found out that the different departments there worked the same way, it was digitals vs. analogs, and IT vs. the rest of the company. IIRC the last financial report from them, they had several millions of cost due to projects that were unexpectedly and severely delayed. Their upper management bought me, because they had no expert. And then couldn't keep me, so they again have no expert. Experts are too difficult. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-02-22 21:16 -0500 |
| Message-ID | <kgbd1v$m79$2@dont-email.me> |
| In reply to | #19907 |
On 2/22/2013 9:56 AM, Bernd Paysan wrote: > Andrew Haley wrote: >> You need to point that arrow of reasoning back at yourself, though: >> you don't like the 8051, so you consider people who choose it to be >> irrational! > > I've had no exposure to the 8051 before that project, I was completely > agnostic at that point of time. I started to hate it when I saw what kind > of crap it was. The b16 came into existence as I was motivated to do > something better, and it took me only *days* to do so. I struggled about > half a year with the various IPs from Inventra (8051, debugger, USB, and > writing test code in 8051 assembler), only to glue them together. > > I've ported Gforth to a competitor of the 8051, the R8C, it took a week to > get Gforth up and running. Is that a Renasas part or the core in the older Cypress PSOC parts? > It is a nice CPU. I also like the msp430. > There are nice CPUs in the 8051 ballpark out there, and there is crapware > like the 8051, and it *does* impact my productivity. After I'm slowed down > for enough time, I start to get emotional. I don't know anyone who thinks the 8051 is a "good" processor. Some like it because it is widely available, familiar to many with lots of tools. I agree that those are not compelling reasons to use it. I think schools would do much better to teach the AVR or MSP430 in their undergraduate classes. >> The truth is that all of us make decisions for emotional >> reasons and save our intellectual firepower to construct elaborate >> rationalizations to justify them. ...snip... > With a more 21st century approach, I would say that emotions is what gives > us drive. It is our brain which decides, and we need emotions to get these > decisions through, so our brain generates these emotions. And yes, we make > "rational" arguments, because following Descartes, we are supposed to be > rational beings. But when those arguments turn out to be factually wrong, > we usually don't redecide. We stick to our emotions, because they provide > more drive than a rational argument. The question wether we came to this > conclusion through an evidence-based approach or through other approaches > doesn't matter. It is probably provable that any thinking thing can't be > understood from the inside. > > http://xkcd.com/1163/ So just what *are* emotions really? There are the base emotions like fear, anxiety, etc. I don't think these are evident in every decision in engineering. I've often wondered what thought processes happen when people design things. I've also wondered how different designs would be from different engineers if given exactly the same inputs. I know that when I look at other people's work it can be hard to figure out what they are thinking. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-02-22 20:28 -0500 |
| Message-ID | <kgbd1t$m79$1@dont-email.me> |
| In reply to | #19903 |
On 2/22/2013 4:59 AM, Andrew Haley wrote: > Bernd Paysan<bernd.paysan@gmx.de> wrote: >> Gary Bergstrom wrote: >>> In the embedded world you should look at how many new chips have an >>> embedded 8051 in them for control. It's hard to spin your own chips >>> using a "informed decision". Easier to buy what is cheap and >>> available. Maybe the vendors will start to switch to some better >>> choice, but I see more and more embedded 8051's every month. >> >> Most decisions people make are irational personal taste decisions. >> Blaise Pascal already noticed that a few centuries ago. It's just >> that way. My personal taste is that the 8051 is utter crap. Though >> there are worse things than the 8051 ;-). > > You need to point that arrow of reasoning back at yourself, though: > you don't like the 8051, so you consider people who choose it to be > irrational! The truth is that all of us make decisions for emotional > reasons and save our intellectual firepower to construct elaborate > rationalizations to justify them. > > Andrew. I've actually given a fair amount of time and energy to this and have come to the realization that even rational thought is emotional. The way we operate internally is through a process of feeling. If we feel good about a decision we go with it and accept it as part of ourselves. When we learn logic, we integrate that logic into ourselves and identify with it. So when we make a "rational" decision using logic, we are simply making ourselves feel good that we are following the rules of logic. But as soon as some other aspect of our emotions generates feelings that overpower the "feel good" of sticking with rational logic, we will depart from it and make "irrational" decisions. Even the process of evaluating a thought process against "rational" logic is fraught with emotion. How many times has someone said, "the equations seem to be telling me this, but it just doesn't 'feel' right"? They literally are talking about how they feel. But to depart from rational thinking generates cognitive dissonance and makes us feel bad. So there are constant battles between the emotions of rational thought and the other emotions. In the end we all follow our emotions no matter how the thought process may look from the outside (or especially how it looks from the inside). We *are* emotional creatures, or as my friend likes to say, "smart little monkeys". At this point I feel I am truly removed from emotions in my work. Of course that may just be another set of emotions making me feel good when I seem to be ignoring my emotions... -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Gary Bergstrom <g.bergstrom@ieee.org> |
|---|---|
| Date | 2013-02-27 07:59 -0800 |
| Message-ID | <ad96b481-7b6c-4c2f-bd8d-7d6a4d1c5c5b@googlegroups.com> |
| In reply to | #19765 |
On Saturday, February 16, 2013 10:35:59 AM UTC-5, Brad Eckert wrote:
> Here's an integer cosine I just wrote that has pretty good precision. Testbench is included. I'm posting it here in case someone wants to add more transcendental functions or if I want to find it again in 20 years.
I like to tinker with such things, but I spend most of my life on 16bit embedded systems, not 32bit or 64bit ones. A lot of the world can be computed with 16bit systems and typically my a/d's are not better than that. But I digress.
I've found it useful, whenever porting to a new processor, to write tight code for a number of math routines:
sqrt, fractional multiply and divide, polynomial evaluation
And using those I can easily drop in a large variety of transcendental functions. See SwiftForth's math add-on file for an example. It's a good start.
I don't normally do 32bit so the below is not optimized. The polynomials should be minimax ones, like the originals from Ganssle. But I didn't have the time - these are simple Taylor terms. So I included enough to make the error drop to a max of about 3 counts. Chebyshev or minimax terms would probably be one term less with similar accuracy. The code should be rewritten with a call to the polynomial evaluation mentioned above.
This code runs somewhat faster (~20%, timing the "worst" routine which means the sin/cos routines run even faster) than the original. Optimizing the coefficients and implementing a polynomial evaluator should make it go even faster. It is larger but my work usually finds that execution time is more valuable than code size. I don't seem to fill flash memory on my little embedded chips.
Jack Crenshaw's book should be on every embedded programmers shelf. At least everyone who does more than adds and subtracts.
Just replace the similar code in Brad's post with that below.
Have fun.
Gary Bergstrom
\ Trig functions in 32-bit Forth
\ Angle input is 32-bit
\ Output range is 0 to +/-$7FFFFFFF, fractional 1.31 format
\ Accuracy is about 30-31 bits, worst case error is about 3 counts
\ See Jack W Crenshaw's book: Math Toolkit for Real-Time Programming
\ The polynomials below are simple Taylor terms (room for improvement)
HEX
6487ED51 CONSTANT S1 295779CC NEGATE CONSTANT S3
0519AF19 CONSTANT S5 4CB4B3 NEGATE CONSTANT S7
2A0F0 CONSTANT S9 F18 NEGATE CONSTANT S11
7FFFFFFF CONSTANT C0 4EF4F326 NEGATE CONSTANT C2
103C1F08 CONSTANT C4 155D3C7 NEGATE CONSTANT C6
F0FA8 CONSTANT C8 69B4 NEGATE CONSTANT C10
40000000 Constant PI/2
20000000 Constant PI/4
DECIMAL
: *. ( f1 f2 -- f=f1*f2 ) M* D2* nip ; \ 80000000 0 D+ NIP ; rounding doesn't seem to help
: <SIN> ( -PI/4<n<PI/4 -- sin<n> ) 2* DUP DUP *. >R
S11 R@ *. S9 + R@ *. S7 + R@ *. S5 + R@ *. S3 + R> *. S1 + *. 2* ;
: <COS> ( -PI/4<n<PI/4 -- cos<n> ) 2* DUP *. >R
C10 R@ *. C8 + R@ *. C6 + R@ *. C4 + R@ *. C2 + R> *. 2* C0 + ;
: SIN ( n -- sin<n> ) DUP PI/4 + DUP >R \ get segment, Jack's book
$C0000000 AND - \ adjust value for segment
R@ $40000000 AND \ the two bits, in number on R, select cos/sin and polarity
IF <COS> ELSE <SIN> THEN
R> 0 < IF NEGATE THEN ;
: COS ( n -- COS<n> ) PI/2 + SIN ;
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2013-02-27 08:48 -0800 |
| Message-ID | <7fb0a556-5469-411b-8b6e-0351992e0b8b@googlegroups.com> |
| In reply to | #20063 |
On Wednesday, February 27, 2013 8:59:42 AM UTC-7, Gary Bergstrom wrote: > > I like to tinker with such things, but I spend most of my life on 16bit embedded systems, not 32bit or 64bit ones. A lot of the world can be computed with 16bit systems and typically my a/d's are not better than that. But I digress. Awesome. I just ordered Jack's book. My A/D is 12-bit, but after 20 ranks of FFT butterflies a few bits of noise creep into the math, and the dynamic range goes over 16-bit too. So 32-bit is a comfy place to be.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web