Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #17603 > unrolled thread
| Started by | Mark Wills <forthfreak@gmail.com> |
|---|---|
| First post | 2012-11-27 08:01 -0800 |
| Last post | 2012-11-28 14:21 +0000 |
| Articles | 20 on this page of 112 — 16 participants |
Back to article view | Back to comp.lang.forth
DTC Mark Wills <forthfreak@gmail.com> - 2012-11-27 08:01 -0800
Re: DTC Paul Rubin <no.email@nospam.invalid> - 2012-11-27 08:55 -0800
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-27 09:01 -0800
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-27 17:42 -0800
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-27 23:50 -0800
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 04:41 -0600
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-28 02:48 -0800
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 05:27 -0600
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-28 03:51 -0800
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-28 21:56 -0800
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-29 01:26 -0800
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-29 22:34 -0800
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-30 01:42 -0800
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-30 13:18 -0800
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-01 01:42 -0800
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-03 15:25 -0800
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-12-03 16:18 -0800
Re: DTC "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-03 21:20 -0500
Re: DTC "Elizabeth D. Rather" <erather@forth.com> - 2012-12-03 17:29 -1000
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-04 00:12 -0800
Re: DTC Paul Rubin <no.email@nospam.invalid> - 2012-12-05 11:35 -0800
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-04 20:17 -0800
Re: DTC Ron Aaron <rambamist@gmail.com> - 2012-12-05 08:31 +0200
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-04 23:48 -0800
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-04 23:53 -0800
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-05 12:13 -0800
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-12-05 15:26 -0800
Re: DTC Ron Aaron <rambamist@gmail.com> - 2012-12-06 06:32 +0200
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-06 01:07 -0800
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-12-06 04:23 -0800
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-06 15:49 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-06 07:42 -0800
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-12-06 08:30 -0800
Re: DTC Paul Rubin <no.email@nospam.invalid> - 2012-12-06 09:45 -0800
Re: DTC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-12-06 21:41 +0000
Re: DTC "A. K." <akk@nospam.org> - 2012-12-06 23:15 +0100
Re: DTC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-12-08 01:27 +0000
Re: DTC "A. K." <akk@nospam.org> - 2012-12-08 11:19 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-08 03:55 -0800
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-08 13:44 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-08 06:05 -0800
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-08 18:35 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-08 11:20 -0800
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-09 01:01 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-08 06:10 -0800
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-08 18:57 +0100
Re: DTC "A. K." <akk@nospam.org> - 2012-12-08 19:46 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-08 11:23 -0800
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-08 13:37 +0100
Re: DTC "A. K." <akk@nospam.org> - 2012-12-08 14:41 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-08 06:15 -0800
Re: DTC "A. K." <akk@nospam.org> - 2012-12-08 17:07 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-06 14:16 -0800
Re: DTC Brad Eckert <hwfwguy@gmail.com> - 2012-12-07 09:00 -0800
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-06 14:21 -0800
Re: DTC "Elizabeth D. Rather" <erather@forth.com> - 2012-12-06 08:01 -1000
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-06 14:18 -0800
Re: DTC "Elizabeth D. Rather" <erather@forth.com> - 2012-12-06 13:48 -1000
Re: DTC "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-06 19:03 -0500
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-12-07 02:59 -0800
Re: DTC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-12-06 13:13 +0000
Re: DTC "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-12-05 20:39 -0500
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-06 15:46 +0100
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-12-06 07:47 -0800
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-12-06 08:36 -0800
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-12-05 04:03 -0800
Re: DTC "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2012-12-06 20:30 -0800
Re: DTC David Thompson <dave.thompson2@verizon.net> - 2012-12-11 23:52 -0500
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-12-12 10:59 -0800
Re: DTC David Thompson <dave.thompson2@verizon.net> - 2012-12-31 02:43 -0500
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-02 00:44 -0800
Re: DTC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-28 13:54 +0000
Re: DTC "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2012-12-06 20:16 -0800
Re: DTC "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-28 06:58 -0500
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-28 04:50 -0800
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 07:08 -0600
Re: DTC Mark Wills <forthfreak@gmail.com> - 2012-11-28 06:02 -0800
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 08:23 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-28 14:18 +0000
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 08:32 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-28 15:00 +0000
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 09:18 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-28 16:36 +0000
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 11:02 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-28 17:13 +0000
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 12:03 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-28 18:12 +0000
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-28 12:32 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-29 14:30 +0000
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-29 18:05 +0100
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-11-29 11:19 -0800
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-30 03:14 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-30 14:12 +0000
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-30 10:32 -0600
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-30 16:40 +0000
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-12-01 15:34 +0000
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-01 21:23 +0100
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-12-03 16:28 +0000
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-03 18:44 +0100
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-12-03 04:50 -0600
Re: DTC Bernd Paysan <bernd.paysan@gmx.de> - 2012-12-03 16:48 +0100
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-12-03 15:59 +0000
Re: DTC albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-30 15:34 +0000
Re: DTC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-30 10:36 -0600
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-30 12:47 -0800
Re: DTC Alex McDonald <blog@rivadpm.com> - 2012-11-28 11:29 -0800
Re: DTC "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-29 04:15 -0500
Re: DTC "Elizabeth D. Rather" <erather@forth.com> - 2012-11-29 08:52 -1000
Re: DTC Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-28 22:25 -0800
Re: DTC "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-29 04:12 -0500
Re: DTC humptydumpty <ouatubi@gmail.com> - 2012-11-28 02:04 -0800
Re: DTC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-28 14:21 +0000
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-12-06 13:13 +0000 |
| Message-ID | <50c099ff$0$3164$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #17869 |
In article <dabba9b6-c352-4cd4-a318-1304e711ebd4@r20g2000yql.googlegroups.com>,
Alex McDonald <blog@rivadpm.com> wrote:
>On Dec 5, 8:13 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>> On Dec 5, 12:48 am, Mark Wills <forthfr...@gmail.com> wrote:
>>
>> > On Dec 5, 6:31 am, Ron Aaron <rambam...@gmail.com> wrote:
>>
>> > > I'm sure Microsoft and Apple would be fascinated to find out their
>> > > software is given away for free!
>>
>> > Well, not all software is given away for free, but an awful lot of it
>> > is. I'd argue that practically all of Apple's software is in fact
>> > given away for free. It's a loss leader to sell the hardware.
>>
>> All software is a loss-leader to sell hardware.
>
>That's (almost) the wrong way round. There is no to little margin in
>most hardware.
Maybe we should start to make a third category: extorsionware.
We have long ago passed from a free market society to an extorsion
society. extorsion ware is where you have government guaranteed
rights to customer money. It is clear that if you control the
governement (and they do!) this paying for IP rights is most
profitable (though profit in the free market sense is no longer
an appropriate word).
"hardware and software both are loss-leaders to extorsion ware."
I can't stand a full 100% behind it, but certainly is more truthful
than what Hugh says.
The big money is in extorsionware, films, records, medicines.
You can also think of the mobile phone market as almost extorsion
ware: the phone is free, then you pay for the right to use
an (originally public funded!) phone net.
Microsoft stuff ("Windows 7") is some 78% extorsion ware, 12%
software. Etc.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-12-05 20:39 -0500 |
| Message-ID | <k9osng$1pf$1@speranza.aioe.org> |
| In reply to | #17866 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:3cfcf1ea-df96-45e4-be03-b6da801b6fb5@m4g2000pbd.googlegroups.com... > On Dec 5, 12:48 am, Mark Wills <forthfr...@gmail.com> wrote: > > On Dec 5, 6:31 am, Ron Aaron <rambam...@gmail.com> wrote: ... > > > I'm sure Microsoft and Apple would be fascinated to find > > > out their software is given away for free! > > > Well, not all software is given away for free, but an awful > > lot of it is. I'd argue that practically all of Apple's > > software is in fact given away for free. It's a loss leader to > > sell the hardware. > > All software is a loss-leader to sell hardware. It's generally the reverse, but can be either, both or neither. > The difference between micro-controllers and desktop-computers, > is that with micro-controllers you are selling the hardware, so > it makes sense for you to provide it with software to give it > value. With desktop-computer software, somebody else (Dell, > etc.) is selling the hardware, and you are providing software to > give it value but not getting paid. The reason why MicroSoft > gets paid, is because they have a deal to bundle their software > with the hardware, and the hardware vendors pay them for this. > Theoretically, MicroSoft will eventually fail when the hardware > vendors switch over to bundling Linux, which makes sense for > them considering that the Linux programmers are willing to work > for free --- [...] Was that the theory? Lol! I'll ignore the fact the "theory" is faulty. Linux has had two decades now ... What happened? > [...] this will never happen though, because > the American federal government has standardized on Windows > for their own bureaus, meaning that MicroSoft has a monopoly > [...] That's first I've heard of that rationale for MS having a monopoly. But, I'd say it's a very good idea to have those who once "attacked" you via abuse of authority as a complicit partner in your "crimes" of monopoly. > Richard Stallman was right when he said that programming is a > service, but that programs aren't products. Is he confused? > The days of programs getting sold > in shrink-wrapped packages containing a pile of disks and a > stack of manuals, is long gone (I bought TASM like that, in > a store's going-out-of-business sale). True. > Nowadays, most programming is done writing software > that will be run once and will become obsolete a week later --- True. > [...] this > is typically software that supports a moving target, such as > health-care billing in which the regulations change almost > daily at the whim of a byzantine bureaucracy. I myself wrote > IBM370 assembly-language software for direct-mail, so the > software became obsolete a week later after the mailing was > done --- the company that I worked for had one of the few > licenses from the Post Office to do that and get the > big discount on postage. So true. Business has to do what is legally required. So, the irrationality inherent in the law is therefore irrelevant. I had to do much the same when programming for the brokerage industry about a decade ago. I had to implement any SEC or regulatory changes in securities law as code to prohibit stock traders from breaking the laws. Of course, I had generally zero help from the legal department to help determine what the laws meant. They were too busy. My direct management was utterly incompetent, i.e., 4 hours of fantasy football, 1 hour of bullshitting, 1 hour in a random meeting that had nothing to do with our department, and a 2 hour lunch with drinking during the allotted one hour lunch break. So, there was generally no help there either. Sometimes, it was impossible to implement. The entire application would've needed to be scrapped. The one time the legal department decided the issue was important enough to "help" me, our in-house legal team spent nearly all day arguing about what the law actually meant. Then, they spent and hour on how it could affect the company, and what it would cost them under various scenarios. Eventually, five minutes before it was time to go home for the day (hint), they decided they'd rather just fight it out in court for a violation of the law than have me implement the law in code. That was the first time I truly wondered why I was there. It was farcical. I felt like becoming an overpaid, underworked, lazy, incompetent, corporate lawyer, just like them. I had no understanding of the law, but I could still do no worse. > It is a battle between fascists and communists --- on one hand > we have the fascists who want MicroSoft to have a monopoly, > and for everybody to pay for their software --- on the other > hand we have the GNU communists who want all software to > be given away for free, but for programmers to get paid by the > hour to make custom upgrades to the software (after investing > years of their own time in writing the software for free). Fascists? Did you mean Socialists? Or, perhaps Capitalists ... ? If not, you may wish to review fascism and socialism: http://en.wikipedia.org/wiki/Fascism http://en.wikipedia.org/wiki/Socialism I.e., communism and socialism are related to an economic system, whereas fascism isn't ... > Neither plan is very good, but I would prefer > communism to fascism --- I prefer capitalism. I'm not quite sure why you mentioned fascism and communism together instead of socialism and communism ... > [...] mostly because I don't think that MicroSoft > is going to hire me. Irrelevant. There are lots of tech companies making money, e.g., Apple, Google. Recently, Apple earned more than Microsoft, Google, eBay, Yahoo!, Facebook, and Amazon combined. If you can program well, someone will hire you. You might not be payed as well as you should be. But, in overpriced or expensive west coast and east coast markets, you can still do well. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-12-06 15:46 +0100 |
| Message-ID | <2623798.mcmh7vNNeK@sunwukong.fritz.box> |
| In reply to | #17853 |
Mark Wills wrote: > Even Winamp, which I am using right now, is free, relying on > donations. Same with the Linux vendors: Entire operating systems given > away for free. Personally I think it's bonkers, it's a race to the > bottom (and we're seeing the same in the mobile entertainment market: > Phone and tablet games) and I take my hat off to companies like Red > Hat who have managed to carve out a profit from their business. What kind of strange misunderstanding of free market economy is behind words like "race to the bottom"? The cost to copy some software is almost zero, which means that the price limit for software sold in high volumes is about zero, and free market economies tend to reach that price limit. It's not a race to the bottom, as this software still is high quality. The business model in 90% of all software development projects is either "pay us for the service" or "pay us for the development", the shelf-ware software had been a small niche, mostly occupied by Microsoft, Adobe, and a few others. Nowadays, we have Apps, but most of them are free-to-download and are add-driven. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-12-06 07:47 -0800 |
| Message-ID | <9610a2d5-9104-483e-8f54-f19e46095388@u19g2000yqj.googlegroups.com> |
| In reply to | #17884 |
On Dec 6, 2:46 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > Mark Wills wrote: > > Even Winamp, which I am using right now, is free, relying on > > donations. Same with the Linux vendors: Entire operating systems given > > away for free. Personally I think it's bonkers, it's a race to the > > bottom (and we're seeing the same in the mobile entertainment market: > > Phone and tablet games) and I take my hat off to companies like Red > > Hat who have managed to carve out a profit from their business. > > What kind of strange misunderstanding of free market economy is behind > words like "race to the bottom"? The cost to copy some software is > almost zero, which means that the price limit for software sold in high > volumes is about zero, and free market economies tend to reach that > price limit. It's not a race to the bottom, as this software still is > high quality. The business model in 90% of all software development > projects is either "pay us for the service" or "pay us for the > development", the shelf-ware software had been a small niche, mostly > occupied by Microsoft, Adobe, and a few others. Nowadays, we have Apps, > but most of them are free-to-download and are add-driven. > > -- > Bernd Paysan > "If you want it done right, you have to do it yourself"http://bernd-paysan.de/ No misunderstanding at all. It's a race to the bottom for the software developers writing the free products. They are actually in competition with their "competitors" to give stuff away for free. "Here, here, take mine, it's free." "No, take mine. It's also free!" Bonkers. Meanwhile, their mother and father is feeding and clothing them to develop software to be given away for free. It's software-socialism, and, like we have seen with all countries that have developed a socialist/communist society, it's a race to the bottom. That's why it's bonkers.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2012-12-06 08:36 -0800 |
| Message-ID | <5eb3ee5a-91f2-49ae-9bbe-0293f8aa277c@w3g2000yqj.googlegroups.com> |
| In reply to | #17888 |
On Dec 6, 3:47 pm, Mark Wills <forthfr...@gmail.com> wrote: > On Dec 6, 2:46 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > > > > > > > > > > > Mark Wills wrote: > > > Even Winamp, which I am using right now, is free, relying on > > > donations. Same with the Linux vendors: Entire operating systems given > > > away for free. Personally I think it's bonkers, it's a race to the > > > bottom (and we're seeing the same in the mobile entertainment market: > > > Phone and tablet games) and I take my hat off to companies like Red > > > Hat who have managed to carve out a profit from their business. > > > What kind of strange misunderstanding of free market economy is behind > > words like "race to the bottom"? The cost to copy some software is > > almost zero, which means that the price limit for software sold in high > > volumes is about zero, and free market economies tend to reach that > > price limit. It's not a race to the bottom, as this software still is > > high quality. The business model in 90% of all software development > > projects is either "pay us for the service" or "pay us for the > > development", the shelf-ware software had been a small niche, mostly > > occupied by Microsoft, Adobe, and a few others. Nowadays, we have Apps, > > but most of them are free-to-download and are add-driven. > > > -- > > Bernd Paysan > > "If you want it done right, you have to do it yourself"http://bernd-paysan.de/ > > No misunderstanding at all. It's a race to the bottom for the software > developers writing the free products. They are actually in competition > with their "competitors" to give stuff away for free. > > "Here, here, take mine, it's free." > "No, take mine. It's also free!" > > Bonkers. > > Meanwhile, their mother and father is feeding and clothing them to > develop software to be given away for free. > > It's software-socialism, and, like we have seen with all countries > that have developed a socialist/communist society, it's a race to the > bottom. > > That's why it's bonkers. It's only bonkers if it's true. Which it isn't; it's a gross mischaracterisation by extrapolating a small %age of software development to an entire industry. Software with no value never gets used. The race is to the top in terms of quality, regardless of price.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2012-12-05 04:03 -0800 |
| Message-ID | <8b46cde6-b05d-40b1-872e-2b91456a7284@8g2000yqp.googlegroups.com> |
| In reply to | #17851 |
On Dec 5, 4:17 am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > On Dec 3, 7:20 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > wrote: > > > The problem with RET on modern x86 - according to those on > > c.l.a.x. - is that it must be _matched_ with a CALL or it causes a > > slowdown of the processor. E.g., the RET location was pushed > > onto the stack via PUSH instead of by a CALL. > > Most of my knowledge of this kind of thing comes form CLAX, most > likely from the same threads that you have been reading. I've also > read some of Intel's optimization manual. See 3.4.1.4 for a discussion > of inlining versus CALL/RET. > > It is true that CALL and RET have to be paired for them to be > optimized. This means that my stack-threading, in which RSP is used as > the Forth IP, won't get optimized, because there are a lot of RET > instructions and no CALL instructions at all. That is not what we are > talking about here though. We are talking about subroutine-threading > (as done by SwiftForth), and the decision of whether to inline a > function or just CALL it. It ends in RET, so the CALL and RET are > paired, which will work. The optimization only works for 16 nesting > levels, but that is not generally a problem. > > Mark is right, that if the sub-function is not in the same 32KB memory > block, then calling it will thrash the cache. If it is close though, > then calling it is better than inlining it. Also, if you mostly call > sub-functions rather than inline them, you save a lot of memory. I > don't know why Alex said that it doesn't save memory, as it obviously > does assuming that the function is larger than a CALL instruction and > it gets called more than once. Calling rather than inlining functions > makes the code less bloated and boosts the chance of the sub-function > being close to the calling function. On my Forth 10 calls means 50 bytes but 25 inlined @ is the same number of bytes. That's shorter, not longer. For 470 extra bytes (3% extra) by inlining words <10 bytes, there's a 25% decrease in CPU time. I can show this; you can't show squat diddly, since you are pulling it out of your ass. > > For the most part, I recommend against just blindly inlining Recommend? Snort! > functions, as done in SwiftForth (for everything defined with ICODE). > You might as well just CALL them rather than inline them, if you > aren't going to do any optimization (in the sense of holding values in > registers, rather than pushing them onto the stack and pulling them > off again). > > Generating machine-code for the x86 was somewhat beyond my knowledge, > which is why I reverted to ITC for HostForth. Nobody cares about the > x86 anyway --- all desktop-computer software is given away for free > --- the only thing that matters is micro-controllers. For this reason, > I have decided to make HostForth fairly simple, and get it to run. > Then I can focus most of my effort on TargForth that generates code > for the micro-controllers, to make it generate efficient code. That > makes sense economically, as micro-controllers get sold for money, so > quality is important. Also, it is easier, as micro-controllers don't > have complicated cache systems, and all of that other complicated > stuff that the x86 has. With the x86, nobody really knows what it does > internally, because the manufacturer won't say because they don't want > to give away trade secrets to their competitors --- the result is that > the assembly-language programmer gets a lot of vague heuristics about > how to optimize his code --- these are like voodoo rituals in that > they seem to work, but you don't know why. By comparison, with the > 80486 we had the u and v pipes, and we could know at compile-time > pretty much exactly what the processor would do at run-time --- life > was much simpler then. > > This is an example of SwiftForth just blindly inlining sub-functions: > > : init-node ( node -- node ) > 0 over ! ; ok > > see init-node > 46E8BF 4 # EBP SUB 83ED04 > 46E8C2 EBX 0 [EBP] MOV 895D00 > 46E8C5 0 # EBX MOV BB00000000 ( 0 ) > 46E8CA 4 # EBP SUB 83ED04 > 46E8CD EBX 0 [EBP] MOV 895D00 > 46E8D0 4 [EBP] EBX MOV 8B5D04 ( OVER ) > 46E8D3 0 [EBP] EAX MOV 8B4500 > 46E8D6 EAX 0 [EBX] MOV 8903 > 46E8D8 4 [EBP] EBX MOV 8B5D04 > 46E8DB 8 # EBP ADD 83C508 ( ! ) > 46E8DE RET C3 ok > > see over > 40383F 4 # EBP SUB 83ED04 > 403842 EBX 0 [EBP] MOV 895D00 > 403845 4 [EBP] EBX MOV 8B5D04 > 403848 RET C3 ok > > see ! > 40335F 0 [EBP] EAX MOV 8B4500 > 403362 EAX 0 [EBX] MOV 8903 > 403364 4 [EBP] EBX MOV 8B5D04 > 403367 8 # EBP ADD 83C508 > 40336A RET C3 ok > > This is how VFX does it: > > : init-code ( node -- node ) > 0 over ! ; ok > see init-code > INIT-CODE > ( 004C7A90 C70300000000 ) MOV DWord Ptr 0 [EBX], > 00000000 > ( 004C7A96 C3 ) NEXT, > ( 7 bytes, 2 instructions ) > ok > > This is how I hand-wrote the same thing in my novice package for > SwiftForth: > > icode init-node ( node -- node ) > eax eax xor eax 0 [ebx] mov ret > > I think VFX's generated code is actually more efficient than my hand- > written code. I recently read in the Intel optimization manual that > register-to-register instructions (such as my xor) are not efficient > nowadays. I wrote my function in the way that I would have written it > for the 80486 --- but that isn't necessarily the best way for the > modern x86. All of this x86 stuff is complicated now, and I don't > really know very much about the subject --- even a simple function About the only true statement in all of this. > such as init-code is a mystery as to how to write it efficiently. :-( Have you ever, ever, ever tested any -- even a single line -- of this bloviating speculation by running a benchmark or pointing to a benchmark or other evidence? Ever? At all? The same problem was apparent in your symtab code; you couldn't demonstrate anything but an ability to write screeds of unsubstantiated opinions masquerading as hard evidence. Much of the above is demonstrably and measurably wrong, and you can't justify a word of it. That's because you assume your audience is just like you. Too damn lazy and too damn stupid to check.
[toc] | [prev] | [next] | [standalone]
| From | "Clyde W. Phillips Jr." <cwpjr02@gmail.com> |
|---|---|
| Date | 2012-12-06 20:30 -0800 |
| Message-ID | <da0dff88-4faa-4810-a2dc-a360b11d534f@googlegroups.com> |
| In reply to | #17658 |
On Wednesday, November 28, 2012 11:56:41 PM UTC-6, Hugh Aguilar wrote: > On Nov 28, 4:51 am, Mark Wills <forthfr...@gmail.com> wrote: > > > On Nov 28, 11:27 am, Andrew Haley <andre...@littlepinkcloud.invalid> > > > wrote: > > > > > > > Mark Wills <forthfr...@gmail.com> wrote: > > > > > On Nov 28, 10:41?am, Andrew Haley <andre...@littlepinkcloud.invalid> > > > > > wrote: > > > > >> Mark Wills <forthfr...@gmail.com> wrote: > > > > >> > On Nov 28, 1:42?am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > > > > > > > >> >> With ITC it is possible to change how a word is interpreted by > > > > >> >> changing the pointer at the cfa. With DTC, by comparison, you don't > > > > >> >> have a pointer to the code that interprets the word, but rather you > > > > >> >> have the code itself pasted in there. > > > > > > > >> > I don't think that's correct, Hugh. > > > > > > > >> I'm sure it is. > > > > > > > > Eh? > > > > > > > I don't understand the problem you're having with my reply. With ITC > > > > it is possible to change how a word is interpreted by changing the > > > > pointer at the cfa. This is simply true, there is no doubt about it, > > > > and your comment is incorrect. > > > > > > > Andrew. > > > > > > Oh. Okay. Yes, I see. I should have read Hugh's reply more closely > > > before posting. > > > > > > So, in the CFA of an ITC system there is a pointer to DOCOL, DOVAR > > > whatever/etc. In DTC it's slightly more complicated, since the CFA > > > field would contain executable code. In my particular processor of > > > choice, the CFA field would be two cells wide. Yes, I can see that > > > patching it to change how it is interpreted could be a pain. Though I > > > suppose a dedicated helper word(s) could be provided to facilitate it. > > > Like Hugh says, it would be quite a rare occurence. > > > > > > Okay. I get it. Sorry for the confusion. > > > > > > Mark > > > > I think that you have got it, but I'm not sure, so I'll go over it > > again: > > > > 1.) In ITC what you have in front of the threaded code of the colon > > word (or the body of the whatever), is a single pointer to the > > interpreter for that kind of word (DOCOLON for colon words, etc.). It > > is easy to store a different pointer in that slot, so the word will be > > interpreted differently (DOCOLON-WITH-SINGLE-STEPPING for colon words, > > for example). > > > > 2.) In DTC what you have in front of the threaded code of the colon > > word (or the body of the whatever), is the actual machine-code of the > > interpreter for that kind of word (DOCOLON for colon words, etc.). It > > is difficult to patch this code, because it is actual code, rather > > than a pointer to some code. > > > > 3.) There is a kind of hybrid between ITC and DTC. This is DTC in the > > sense that we have machine-code in front of each word. However, this > > machine-code always consists of a single CALL instruction to DOCOLON > > etc.. When a CALL is executed, it puts the address just after itself > > on the processor return-stack. Normally this is for RET to use to go > > back. Here is the clever part though: this is the address of the body > > of the Forth word. DOCOLON can load this address into the IP and begin > > interpreting. In this case, you get DTC which is faster than ITC, but > > you also get an easy way to change how a word is interpreted (just > > store a new pointer into the operand of the CALL instruction). > > > > The PDP-11 had an interesting feature. The JSR (its term for CALL) > > would store the address after itself into a register, and it would > > first push that register onto the return-stack. Effectively, the top > > value of the return-stack was held in a register. But that register > > could be your IP! You have DTC code and just do a JSR to DOCOLON (#3 > > above), and DOCOLON automatically gets the address of the threaded > > code loaded into the IP. I figured this out way back in 1985 when I > > was taking a class in assembly-language at the city college, which was > > PDP-11. This works so well, that I had to suppose that the designers > > of the PDP-11 were Forth programmers, or at least, were trying to > > support DTC threaded code. I've never seen this feature on any other > > processor. Even in 1985 though, the PDP-11 was obsolete --- the city > > college was still teaching it just because they had all the textbooks, > > but the professor cheerfully admitted that the PDP-11 was obsolete and > > we would never use what we learned in the real world. I've always > > thought that the PDP-11 was pretty cool though --- I wish somebody > > would come out with a micro-controller that runs PDP-11 code and RT11 > > and all that --- maybe on an FPGA. > > > > BTW: There is a discussion of threading over on comp.lang.asm.x86: > > https://groups.google.com/group/comp.lang.asm.x86/browse_thread/thread/971adcb57df96272 > > > > Mark: Since your TI Forth system is ITC, why don't you take a stab at > > writing a single-step source-level debugger? As I mentioned, I wrote > > one for my 65c02 system. It is not as difficult as you might suppose. > > I did it with screen-file source-code. It can be done with seq-file > > source-code though, I would suppose. I don't think that a debugger is > > all that useful, but writing one is pretty interesting --- and your > > users will be impressed. :-) > > > > Have fun! Hugh Good points Hugh. I too didi the PDP-11 asm test. You get lambasted a lot but this is coo with me.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2012-12-11 23:52 -0500 |
| Message-ID | <n43gc8l96tl6vrol55i6hreb3il7mmtta4@4ax.com> |
| In reply to | #17658 |
On Wed, 28 Nov 2012 21:56:41 -0800 (PST), Hugh Aguilar <hughaguilar96@yahoo.com> wrote: <snip ITC vs DTC vs ?> > The PDP-11 had an interesting feature. The JSR (its term for CALL) > would store the address after itself into a register, and it would > first push that register onto the return-stack. Effectively, the top > value of the return-stack was held in a register. But that register Yes. Although as a special case if you use R7 which is the PC as the "linkage" register, this collapses to just push bumped-PC. > could be your IP! You have DTC code and just do a JSR to DOCOLON (#3 > above), and DOCOLON automatically gets the address of the threaded > code loaded into the IP. I figured this out way back in 1985 when I > was taking a class in assembly-language at the city college, which was > PDP-11. This works so well, that I had to suppose that the designers > of the PDP-11 were Forth programmers, or at least, were trying to > support DTC threaded code. I've never seen this feature on any other > processor. Even in 1985 though, the PDP-11 was obsolete --- the city More likely they were supporting inline (in code) arguments. Most(?) earlier DEC machines had only 1 or 2 manipuable registers, and no (hardware) stack support, so the usual practice had been to put the arguments following the call instruction; the callee uses the "return pointer" to access the arguments, bumping as it goes, and then returns to the bumped value. I know PDP-11 FORTRAN did this, and other languages likely did also. For some DEC machines this wasn't even a register; the return pointer was stored in memory at the callee, so every argument access was an indirect through memory and an increment of memory. Of course this didn't support recursion easily or re-entrancy, but in those days that was acceptable. The notable exception was the PDP-10 and IINM its predecessor the PDP-6. That had all three linkage methods: on stack (with multiple stacks possible but IME not often used), in GP register, or in memory at callee. But the -6 and -10 were much bigger and more expensive than the rest of the DEC line before VAX -- which architecturally defines the argument list, and allows it either on the (single-per-mode C-etc-style) stack or in arbitrary memory which is usually in the same module as, but not inline after, the call instruction. <snip rest>
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-12-12 10:59 -0800 |
| Message-ID | <5d604448-3182-45d3-a68a-788d0cbd1dae@uc4g2000pbc.googlegroups.com> |
| In reply to | #17980 |
On Dec 11, 9:52 pm, David Thompson <dave.thomps...@verizon.net> wrote: > On Wed, 28 Nov 2012 21:56:41 -0800 (PST), Hugh Aguilar<hughaguila...@yahoo.com> wrote: > > <snip ITC vs DTC vs ?> > > > The PDP-11 had an interesting feature. The JSR (its term for CALL) > > would store the address after itself into a register, and it would > > first push that register onto the return-stack. Effectively, the top > > value of the return-stack was held in a register. But that register > > Yes. Although as a special case if you use R7 which is the PC as the > "linkage" register, this collapses to just push bumped-PC. That is true. > > could be your IP! You have DTC code and just do a JSR to DOCOLON (#3 > > above), and DOCOLON automatically gets the address of the threaded > > code loaded into the IP. I figured this out way back in 1985 when I > > was taking a class in assembly-language at the city college, which was > > PDP-11. This works so well, that I had to suppose that the designers > > of the PDP-11 were Forth programmers, or at least, were trying to > > support DTC threaded code. I've never seen this feature on any other > > processor. Even in 1985 though, the PDP-11 was obsolete --- the city > > More likely they were supporting inline (in code) arguments. Most(?) > earlier DEC machines had only 1 or 2 manipuable registers, and no > (hardware) stack support, so the usual practice had been to put the > arguments following the call instruction; the callee uses the "return > pointer" to access the arguments, bumping as it goes, and then returns > to the bumped value. I know PDP-11 FORTRAN did this, and other > languages likely did also. For some DEC machines this wasn't even a > register; the return pointer was stored in memory at the callee, so > every argument access was an indirect through memory and an increment > of memory. Of course this didn't support recursion easily or > re-entrancy, but in those days that was acceptable. > > The notable exception was the PDP-10 and IINM its predecessor the > PDP-6. That had all three linkage methods: on stack (with multiple > stacks possible but IME not often used), in GP register, or in memory > at callee. But the -6 and -10 were much bigger and more expensive than > the rest of the DEC line before VAX -- which architecturally defines > the argument list, and allows it either on the (single-per-mode > C-etc-style) stack or in arbitrary memory which is usually in the same > module as, but not inline after, the call instruction. That is what the instructor told the class; that the feature was for passing data into sub-functions. This didn't make much sense as it isn't much different than just passing data in global variables. The instructor said it was mostly used for string constants. He taught us to pass data in registers. I think they had a system in which data was passed in a C-style stack frame, but I never got that far in school. I'm not familiar with the early machines. The high-school where I went had a PDP-8, but I only programmed in BASIC at that time. I've never actually seen a PDP-11 --- that class I took emulated it on a VAX, as the PDP-11 was already obsolete by then. Is the PDP-11 still used at all? I would assume that this would be in an FPGA soft-core if it exists (that is how the 65c02 lives on). By modern standards, the PDP-11 would be roughly comparable to the MSP430 --- it only has 8 registers rather than 16, but it has better addressing modes (both auto-inc and auto-dec). The PDP-11 wouldn't be as powerful as the PIC24 though, as it doesn't have Harvard architecture, and not as many registers. Still though, the PDP-11 would be adequate for most micro-controller projects. That would be a real blast from the past! :-)
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2012-12-31 02:43 -0500 |
| Message-ID | <pdg2e8lg1bglgg3e66v7eg91f5hs5c8f75@4ax.com> |
| In reply to | #17987 |
On Wed, 12 Dec 2012 10:59:44 -0800 (PST), Hugh Aguilar <hughaguilar96@yahoo.com> wrote: > On Dec 11, 9:52 pm, David Thompson <dave.thomps...@verizon.net> wrote: > > On Wed, 28 Nov 2012 21:56:41 -0800 (PST), Hugh Aguilar<hughaguila...@yahoo.com> wrote: > > > > <snip ITC vs DTC vs ?> > > > > > The PDP-11 had an interesting feature. The JSR (its term for CALL) > > > would store the address after itself into a register, and it would > > > first push that register onto the return-stack. Effectively, the top > > > value of the return-stack was held in a register. But that register > > > > Yes. Although as a special case if you use R7 which is the PC as the > > "linkage" register, this collapses to just push bumped-PC. > > That is true. > > > > could be your IP! You have DTC code and just do a JSR to DOCOLON (#3 > > > above), and DOCOLON automatically gets the address of the threaded > > > code loaded into the IP. I figured this out way back in 1985 when I > > > was taking a class in assembly-language at the city college, which was > > > PDP-11. This works so well, that I had to suppose that the designers > > > of the PDP-11 were Forth programmers, or at least, were trying to > > > support DTC threaded code. I've never seen this feature on any other > > > processor. Even in 1985 though, the PDP-11 was obsolete --- the city > > > > More likely they were supporting inline (in code) arguments. Most(?) > > earlier DEC machines had only 1 or 2 manipuable registers, and no > > (hardware) stack support, so the usual practice had been to put the > > arguments following the call instruction; the callee uses the "return > > pointer" to access the arguments, bumping as it goes, and then returns > > to the bumped value. I know PDP-11 FORTRAN did this, and other > > languages likely did also. <snip> > > That is what the instructor told the class; that the feature was for > passing data into sub-functions. This didn't make much sense as it > isn't much different than just passing data in global variables. The They're both in memory, but this does keep the data or at least pointers at the call site which was a minor convenience, and it saves some copies and uses shorter=faster insns which never hurt. > instructor said it was mostly used for string constants. He taught us > to pass data in registers. I think they had a system in which data was > passed in a C-style stack frame, but I never got that far in school. > There's no technical connection to string constants. A particular program might happen to have many passed arguments that are string constants. More generally, I can imagine a convention that passes small variable things in the few available registers, and larger and/or constant things "inline" (at the JSR-ed linkage address). If you did that, especially back in the 80s, it wouldn't surprise me if most or all strings in most programs were constant (labels and texts for printouts/displays, and error messages) while many numbers were input and/or computed hence variable. > I'm not familiar with the early machines. The high-school where I went > had a PDP-8, but I only programmed in BASIC at that time. I've never > actually seen a PDP-11 --- that class I took emulated it on a VAX, as > the PDP-11 was already obsolete by then. > > Is the PDP-11 still used at all? I would assume that this would be in > an FPGA soft-core if it exists (that is how the 65c02 lives on). By Well, there is a fairly active group of hobbyists and preservationists (on comp.sys.pdp11) who keep, salvage, repair, and run a few, and even do things like y2k fixes to software that the vendor stopped selling well before 2000; it's arguable whether that counts as real "use". Some of those people occasionally post about being called on to support machines that are still in use, mostly in applications that would be difficult to replace, like industrial controls. I would guess there are more of those than reported publicly but not very many. There is a software simulator, in a group of simulators for 50s-70s machines called simh by Bob Supnik http://simh.trailing-edge.com/ . While googling something else I saw http://opencores.org/project,w11 and there may well be others (I didn't search). > modern standards, the PDP-11 would be roughly comparable to the MSP430 > --- it only has 8 registers rather than 16, but it has better > addressing modes (both auto-inc and auto-dec). The PDP-11 wouldn't be > as powerful as the PIC24 though, as it doesn't have Harvard > architecture, and not as many registers. Still though, the PDP-11 > would be adequate for most micro-controller projects. That would be a > real blast from the past! :-) Some higher-end models -- definitely 11/45 and 11/70, and I think 11/60 and maybe another I forget -- had memory management units which could map Instruction fetches differently than Data accesses. This capability was called, rather unimaginitively, "separate I&D space" and was supported by Bell Labs Unix, so you could have 64KB code and 64KB data+gap+stack, per process -- given enough physical memory. The MMU could also make 8KB pages of each space readonly, although I'm pretty sure Labs Unix protected all the insn space and none of the data space -- in those days C did not yet have the idea of 'const'. (For non-I&D models, Labs Unix definitely could protect -- and share -- the lower pages of the address space containing pure code, leaving unprotected the data and stack in the upper pages.) But still limited to 8 registers and 2 of them reserved. It is (or was) a pretty nice instruction set to write in assembler. But who cares about that today?
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2013-01-02 00:44 -0800 |
| Message-ID | <8d02d307-0900-4406-a595-4b85de5bb0ff@px4g2000pbc.googlegroups.com> |
| In reply to | #18355 |
On Dec 31 2012, 12:43 am, David Thompson <dave.thomps...@verizon.net> wrote: > But still limited to 8 registers and 2 of them reserved. With mass-produced chips, it is possible to have a lot more registers. Even low-cost processors such as the PIC24 and MSP430 have 16. When building a custom chip on a PLD though, there isn't room for very many registers. That was true in 1995 when Testra made the MiniForth, and it likely is still true today, although to a lessor degree. I don't really know anything about FPGA, although I suppose it has similar limitations as a PLD. (Actually, I don't know anything about PLD either, as all I did was write the assembler/compiler/simulator, but didn't contribute to the design of the processor at all.) > It is (or was) a pretty nice instruction set to write in assembler. > But who cares about that today? Compiler-writers!
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-28 13:54 +0000 |
| Message-ID | <50b61779$0$3184$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #17624 |
In article <25-dnfvDKpqEaCjNnZ2dnUVZ8mGdnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Mark Wills <forthfreak@gmail.com> wrote: >> On Nov 28, 10:41?am, Andrew Haley <andre...@littlepinkcloud.invalid> >> wrote: >>> Mark Wills <forthfr...@gmail.com> wrote: >>> > On Nov 28, 1:42?am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: >>> >>> >> With ITC it is possible to change how a word is interpreted by >>> >> changing the pointer at the cfa. With DTC, by comparison, you don't >>> >> have a pointer to the code that interprets the word, but rather you >>> >> have the code itself pasted in there. >>> >>> > I don't think that's correct, Hugh. >>> >>> I'm sure it is. >> >> Eh? > >I don't understand the problem you're having with my reply. With ITC >it is possible to change how a word is interpreted by changing the >pointer at the cfa. This is simply true, there is no doubt about it, >and your comment is incorrect. This may be a good opportunity to show how nice ITC is in this respect. The possibility to "patch" an existing word is used in ciforth all over the place. Technically it patches the dfa not the cfa as it replaces a pointer to high level code. So no change to assembler code is needed. 1. You can turn the dictionary (FIND) into a case insensitive one. 2. you can print the stack after each execution, or change the prompt 3. You can turn a word into a postfix word for once, then it flips back. 4. It is used for turnkeys, by patching into ABORT 5. ?ERROR is patched to allow better error recovery 6. Revectoring I/O by patching TYPE. (Intentionally all output is via TYPE) 7. ALIAS works by copying three words, works for low level too. 8. Run time buffers, that don't take up space in the executable (dfa) 9. Changing in CONSTANT afterwards. > >Andrew. -- 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 | "Clyde W. Phillips Jr." <cwpjr02@gmail.com> |
|---|---|
| Date | 2012-12-06 20:16 -0800 |
| Message-ID | <2777cecb-e181-4a7a-a0bf-b007cd8d462b@googlegroups.com> |
| In reply to | #17631 |
On Wednesday, November 28, 2012 7:54:01 AM UTC-6, Albert van der Horst wrote: > In article <25-dnfvDKpqEaCjNnZ2dnUVZ8mGdnZ2d@supernews.com>, > > Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > > >Mark Wills <forthfreak@gmail.com> wrote: > > >> On Nov 28, 10:41?am, Andrew Haley <andre...@littlepinkcloud.invalid> > > >> wrote: > > >>> Mark Wills <forthfr...@gmail.com> wrote: > > >>> > On Nov 28, 1:42?am, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > > >>> > > >>> >> With ITC it is possible to change how a word is interpreted by > > >>> >> changing the pointer at the cfa. With DTC, by comparison, you don't > > >>> >> have a pointer to the code that interprets the word, but rather you > > >>> >> have the code itself pasted in there. > > >>> > > >>> > I don't think that's correct, Hugh. > > >>> > > >>> I'm sure it is. > > >> > > >> Eh? > > > > > >I don't understand the problem you're having with my reply. With ITC > > >it is possible to change how a word is interpreted by changing the > > >pointer at the cfa. This is simply true, there is no doubt about it, > > >and your comment is incorrect. > > > > This may be a good opportunity to show how nice ITC is in this > > respect. > > > > The possibility to "patch" an existing word is used in ciforth all > > over the place. > > Technically it patches the dfa not the cfa as it replaces a pointer > > to high level code. So no change to assembler code is needed. > > > > 1. You can turn the dictionary (FIND) into a case insensitive one. > > 2. you can print the stack after each execution, or change the prompt > > 3. You can turn a word into a postfix word for once, then it flips > > back. > > 4. It is used for turnkeys, by patching into ABORT > > 5. ?ERROR is patched to allow better error recovery > > 6. Revectoring I/O by patching TYPE. (Intentionally all output is via TYPE) > > 7. ALIAS works by copying three words, works for low level too. > > 8. Run time buffers, that don't take up space in the executable (dfa) > > 9. Changing in CONSTANT afterwards. > > > > > > > >Andrew. > > -- > > 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 I Like your points here. In ITC is it as simple as the cfa either points to inline asm code or another address pointing to system standards such as DOCOL's asm code, other primitives, and such. Clyde
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-28 06:58 -0500 |
| Message-ID | <k94u0o$jep$1@speranza.aioe.org> |
| In reply to | #17617 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:0782b510-4476-423b-b520-fa0fb1a730c6@r10g2000pbd.googlegroups.com... > On Nov 27, 9:01 am, Mark Wills <forthfr...@gmail.com> wrote: ... > > One thing that struck me, it mentions that direct threaded is > > not as "flexible" as ITC. I was wondering in what respect > > DTC is less flexible? Anyone have any opinions/comments? > > With ITC it is possible to change how a word is interpreted by > changing the pointer at the cfa. With DTC, by comparison, you > don't have a pointer to the code that interprets the word, but > rather you have the code itself pasted in there. It is a major > hassle to patch this code to change how the word is interpreted. True. With DTC, you need an assembler, since the code is inlined with the definition's data. With ITC, the Forth can be written in a HLL language or assembly. This is because of the CFA pointer allowing you to assign a function or primitive or low-level word etc which determines how each word is processed. The CFA pointer allows the common code routines to be separated from the definition's data. By common code routines, I mean DOCOL or ENTER, DOSEMIS or EXIT, DOVAR, DOCON, etc. If there are CFA "primitives" for constants and variables, why it there is no DOSTR (do string) in Forth? And, if there is no DOSTR, e.g., Forth has S" , then are DOCON and DOVAR really needed? > My application program was a symbolic > math program that would do calculus --- I got as far as > determining the derivative of a function, and reducing the > equation to simplest terms, but never got as far as symbolic > integration of functions, which is much more difficult. You should talk about that instead of your slide-rule or novice packages. Did you use Laplace transforms to solve the calculus equations? If you're not familiar with them, they can convert many, but not all, calculus problems into algebra problems. There is a set of constraints which must be true before using the transforms. > I don't mess with debuggers nowadays --- Paul Rubin may find > this hard to believe, but it is not because I don't know how to > write a debugger, but it is because I find testing functions at > the console immediately after writing them to be more efficient. If you can display data and rewrite and/or recompile the code, who need a debugger? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-28 04:50 -0800 |
| Message-ID | <9247b279-1506-4cbe-a9e8-d993747cac04@w7g2000vbb.googlegroups.com> |
| In reply to | #17627 |
On Nov 28, 11:58 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > > With DTC, you need an assembler, since the code is inlined with > the definition's data. With ITC, the Forth can be written in a > HLL language or assembly. This is because of the CFA pointer > allowing you to assign a function or primitive or low-level word > etc which determines how each word is processed. The CFA pointer > allows the common code routines to be separated from the > definition's data. By common code routines, I mean DOCOL or > ENTER, DOSEMIS or EXIT, DOVAR, DOCON, etc. If there are CFA > "primitives" for constants and variables, why it there is no DOSTR > (do string) in Forth? And, if there is no DOSTR, e.g., Forth has > S" , then are DOCON and DOVAR really needed? > Forth *does* have a DOSTR. In my system it's called (S"). It gets compiled into a definition with the string data immediately after it: : test S" HELLO" ; see test test: docol (s") 5 h e l l o exit Regarding DTC, dealing with the CFA for patching purposes is only *marginally* more complex, and depending on the processor may not be any more complex at all. Like you say, in an ITC you have a *pointer* to code that either calls DOCOL DOVAR etc, or, if it's a primitive, the pointer points at the machine code. In a DTC, the CFA is a CALL or a BRANCH/JMP etc to the 'handler' (DOCOL et al). The rest of the thread is a thread of addresses. See the Rodriguez article I linked above. I'm sure you've seen it before. On my system, the CFA would need 2 cells; 1 cell holds the branch instruction, the other holds the address of the 'handler'. So, to patch it, I'd need to target the 2nd cell of the CFA. Words could be provided to do this without the programmer having to worry about the internals. In my case, I *could* get away with a single cell CFA, but I'd need to store the addresses of the routines in registers and use an indirect branch. But that's a waste of registers. So, Hugh was spot on. The *particular example he cited* is an example of some additional *complexity* though the DTC method (IMO) remains no less *flexible* - there's nothing that DTC can't do that ITC can (as far as I can discern). Even vectoring (for example) via a variable should work just fine: variable vector ' thing vector ! vector @ execute I can see no complicating factor in the above in the context of a DTC system. I'm simply interested, because in my case, I can get some performance improvements. I can (I think) lose NEXT althogether. NEXT would effectively become a single assembly language instruction: B *IP+ (branch to the *contents* of IP register and increment IP register). If it's a single instruction, then obviously you just inline it at the end of all your words, you don't branch to it! Also, from a boot-strapping perspective, I see no limitation in coding words in Forth itself once the nucleus is up and running; a definition is (with the exception of the CFA) a thread of addresses. In the source code of the kernal, these would simply be symbolic addresses.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-28 07:08 -0600 |
| Message-ID | <ZPOdnZXtCM5UkSvNnZ2dnUVZ8imdnZ2d@supernews.com> |
| In reply to | #17629 |
Mark Wills <forthfreak@gmail.com> wrote: > In a DTC, the CFA is a CALL or a BRANCH/JMP etc to the > 'handler' (DOCOL et al). No: in some cases it's the actual code. Consider a CONSTANT, for example. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-28 06:02 -0800 |
| Message-ID | <dddb3499-4cbe-41bf-9a7b-5f38bc2afbab@r3g2000vbn.googlegroups.com> |
| In reply to | #17630 |
On Nov 28, 1:08 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Mark Wills <forthfr...@gmail.com> wrote: > > In a DTC, the CFA is a CALL or a BRANCH/JMP etc to the > > 'handler' (DOCOL et al). > > No: in some cases it's the actual code. Consider a CONSTANT, for > example. > > Andrew. Good point. I think I see where you're leading me with this :-) It could lead to complications with words like >BODY for example, where a CFA might not strictly be a 1 or 2 cell wide field. Again, in my case, I could get around that: 10 CONSTANT TEN Would lay down something like: DOCON NOP 10 ~~~~~~~~~ ~~ | | 2 field PFA CFA The NOP wouldn't actually be executed - it's just filler to line the PFA up to make the implementation of words such as >BODY simpler. IIRC I came across this particular issue early on in my ITC system when implementing DOES>
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-28 08:23 -0600 |
| Message-ID | <d9ydnfEY0uvxgyvNnZ2dnUVZ8g2dnZ2d@supernews.com> |
| In reply to | #17632 |
Mark Wills <forthfreak@gmail.com> wrote: > On Nov 28, 1:08?pm, Andrew Haley <andre...@littlepinkcloud.invalid> > wrote: >> Mark Wills <forthfr...@gmail.com> wrote: >> > In a DTC, the CFA is a CALL or a BRANCH/JMP etc to the >> > 'handler' (DOCOL et al). >> >> No: in some cases it's the actual code. Consider a CONSTANT, for >> example. > > Good point. I think I see where you're leading me with this :-) > > It could lead to complications with words like >BODY for example, > where a CFA might not strictly be a 1 or 2 cell wide field. In DTC there may not be a CFA. > Again, in my case, I could get around that: > > 10 CONSTANT TEN > > Would lay down something like: > > DOCON NOP 10 > ~~~~~~~~~ ~~ > | | > 2 field PFA > CFA > > The NOP wouldn't actually be executed - it's just filler to line the > PFA up to make the implementation of words such as >BODY simpler. Well, you could, but it would be rather lame IMO: you'd be throwing away an excellent optimization opportunity, and for what? CONSTANTs don't have bodies anyway. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-28 14:18 +0000 |
| Message-ID | <2012Nov28.151829@mips.complang.tuwien.ac.at> |
| In reply to | #17630 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Mark Wills <forthfreak@gmail.com> wrote:
>
>> In a DTC, the CFA is a CALL or a BRANCH/JMP etc to the
>> 'handler' (DOCOL et al).
>
>No: in some cases it's the actual code. Consider a CONSTANT, for
>example.
Why constants? I would expect that on most DTC systems there is a
"JMP/CALL DOCON" at the start of a constant.
For primitives, though, the code address points to the actual code,
not to a jump to the code.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-28 08:32 -0600 |
| Message-ID | <vvudnQz89O3zvSvNnZ2dnUVZ7tudnZ2d@supernews.com> |
| In reply to | #17634 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Mark Wills <forthfreak@gmail.com> wrote: >> >>> In a DTC, the CFA is a CALL or a BRANCH/JMP etc to the >>> 'handler' (DOCOL et al). >> >>No: in some cases it's the actual code. Consider a CONSTANT, for >>example. > > Why constants? I would expect that on most DTC systems there is a > "JMP/CALL DOCON" at the start of a constant. It's possible, but a pretty crappy implementation. Why would you do that when there's such an obvious speedup? Andrew.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web