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 | 12 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-12-03 16:48 +0100 |
| Message-ID | <3305983.3dZSVTLMbE@sunwukong.fritz.box> |
| In reply to | #17818 |
Andrew Haley wrote: > It's the cache line granularity that really matters, though: you won't > gain anything from separating headers and words unless more words in > your working set share the same cache lines. A word that's only 20 > bytes long may occupy a line of its own regardless of whether its > headers are in the same space. But usually, you do have spatial locality, you have several factors close together and you will use them together. Desktop CPUs usually have an abundance of cache, but having to fetch a whole cache line for a single variable just because it is surrounded by header and code field is not very efficient. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-12-03 15:59 +0000 |
| Message-ID | <2012Dec3.165958@mips.complang.tuwien.ac.at> |
| In reply to | #17818 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> The way I think about this is not on a per-word basis. Instead,
>> consider the working set of the application: Does it fit in the
>> I-Cache and in the D-Cache, or conversely, how big would they have
>> to be to fit? If you mix code with read-only data, the working-set
>> will grow (both in the I-cache and in the D-cache), and if the
>> caches are smaller than the working set, you will have more misses
>> in these caches.
>
>It's the cache line granularity that really matters, though: you won't
>gain anything from separating headers and words unless more words in
>your working set share the same cache lines.
Sure. And if the code for a word does not just happen to start at the
start of a cache line and is exactly one cache line long, then yes,
more words in the working set do share the same cache lines.
>A word that's only 20
>bytes long may occupy a line of its own regardless of whether its
>headers are in the same space.
That leaves 12 or 44 bytes for the code of the next word.
If you have 3 20-byte words and you don't mix them up with headers,
together they can occupy 2 32-byte or 1 64-byte cache line. If you
pad the code to start each word at a new cache line, it occupies at
least 3 cache lines, if you mix code with headers, it's three cache
lines or more; if you mix headers with code and use padding, you need
three cache lines for the code, but the code is distributed more
sparsely, which leads to higher miss rates for low-associativity
caches.
- 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-30 15:34 +0000 |
| Message-ID | <50b8d1e8$0$3164$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #17754 |
In article <DKKdnRsQzsib5CXNnZ2dnUVZ8gednZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> wrote: >> Andrew Haley wrote: >>> You'll have to explain that a bit more; I don't understand the point >>> you're making. >> >> Let's give some typical code you can find in many applications; in this >> case we use it as micro-benchmark, it's a variable and the corresponding >> modifier function side by side: > >Umm no, that's not what I was asking. I was asking why Anton said no >when as far as I could tell he was agreeing with me. But never mind. > >> The lesson lerned is that: >> >> * You should separate code and data >> * VFX does a good job now on variables, but on CREATEd words, it is >> accidential >> * bigForth doesn't, and as it compiles dense code without additional >> information, it quickly exposes the problem >> * If you use such a system, declare your variables first, add maybe some >> padding, and then write your code >> >> If I was going to write another code generator, I'd very likely use >> Gforth's approach: EXECUTE has an indirection (this is pretty cheap >> on current CPUs), and the dictionary contains variables, headers, >> and pointer to the actual code, but not the code itself. It might >> also be possible to change CREATE so that it uses a different area >> for code and data, so that having a direct EXECUTE is possible. > >I don't understand the point of this. Surely you just put everything >write-once (which includes the code and the dictionary entries) in one >area and everything variable (HERE and ALLOT) in another. EXECUTE >doesn't need an indirection because ' can return a code address; >only >BODY needs the indirection. You don't seem to appreciate that some processor have their code and data separate to the point that data can't be reached to execute, and code can't be read. > >Andrew. 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-30 10:36 -0600 |
| Message-ID | <8cudneeQd9PrfSXNnZ2dnUVZ8nWdnZ2d@supernews.com> |
| In reply to | #17771 |
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > > You don't seem to appreciate that some processor have their code and > data separate to the point that data can't be reached to execute, > and code can't be read. You're right, I don't: even the likes of 8051 allow data to be put into code space. Such bizarre animals as you describe, obviously, require special-purpose handling, and you have to do whatever they need. There's no point discussing what's best for them. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-11-30 12:47 -0800 |
| Message-ID | <df410759-bc76-4801-bb21-400ac53ea6b0@vy11g2000pbb.googlegroups.com> |
| In reply to | #17773 |
On Nov 30, 9:36 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > > > > > You don't seem to appreciate that some processor have their code and > > data separate to the point that data can't be reached to execute, > > and code can't be read. > > You're right, I don't: even the likes of 8051 allow data to be put > into code space. Such bizarre animals as you describe, obviously, > require special-purpose handling, and you have to do whatever they > need. There's no point discussing what's best for them. > > Andrew. Harvard architecture computers are "bizarre animals" to you? The MiniForth was Harvard Architecture. It is a pretty common architecture. Modern processors such as the x86 are nominally von-Neumann architecture, but they actually have a code cache and a data cache which are distinct from each other --- so they work a lot more efficiently if you keep your code and data separate, as if it were a Harvard architecture computer. Also, there are what I call "pseudo-Harvard" architecture. This includes the 8051 mentioned above. These have code and data in separately addressed spaces, although they can only access one or the other at a time, but can't access both simultaneously like in a Harvard architecture computer. They do this primarily to double the amount of memory that they can access. The 8051, although it has a 16- bit address bus, can access 64K of code and 64K of data (plus the direct memory, which is yet another address space). This was also done with the 65c02 in a few cases --- there were computers that could distinguish whether a bus access was code or data and would switch memory banks appropriately --- none of the personal computers did it, but this is something that I heard about.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2012-11-28 11:29 -0800 |
| Message-ID | <4bdd1cb8-dd63-4168-9a58-6e1f5b070c99@o30g2000vbu.googlegroups.com> |
| In reply to | #17642 |
On Nov 28, 5:13 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >> On IA-32 and AMD-64, you would get a big slowdown for many programs
> >> unless you separate the generated native code from the threaded code
> >> (which requires additional work that has not made it into a number of
> >> native code systems yet, 16 years after the issue became known).
>
> >Err, why would
>
> > mov r0, #1
> > jmp push
>
> >be slower than
>
> > call docon
> > ... the constant 1
>
> >? The latter mixes code and data in the same memory area, the former
> >doesn't.
>
> Good point. Yes, I found that ITC-like DTC is slower than ITC,
> because of this issue.
>
> >Besides, last time I looked the only penalty was for a write
> >to the same cache line as the code; that's irrelevant here.
>
> I guess that myopic view is what causes the persistence of this
> problem. Now consider:
>
> variable foo
> 1 constant bar
> variable boing
> : flip bar foo ! bar boing ! ;
> flip
>
> Many native code Forth systems have bet on written data not being in
> the same cache line as code, and lost; and actually "not being in the
> same cache line" is not enough, thanks to prefetching.
>
variable foo ok
1 constant bar ok
variable boing ok
: flip bar foo ! bar boing ! ; ok
see flip
: flip ( ? -- ? )
\ std call compiles; code=$41A76C len=20 type=1
\ defined in (console)
( $0 ) mov dword { $805164 } $1 \
C7056451800001000000
( $A ) mov dword { $805168 } $1 \
C7056851800001000000
( $14 ) ret \ C3 ( end ) ok
There are separate code and data areas in this native code Forth
(actually, it's a mixture of ITC and STC) as can be seen from the code
address and the addresses of the variables. On the micro benchmark
from Stephen Pelc's website, the speedup in having code and data in >
cache line distant areas is huge. If I force the code section to the
data section and use a traditional single space, the slowdown is 2.5-3
times; and the timings are very variable from run to run.
There are other advantages, although you can't do anything with this
"feature" given the ANS spec;
create x
10 value a
20 value b
A and B are adjacent cells, so x 2@ works as though this had been
specified as
create x 10 , 20 ,
[snip]
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-29 04:15 -0500 |
| Message-ID | <k978pt$5p2$1@speranza.aioe.org> |
| In reply to | #17629 |
"Mark Wills" <forthfreak@gmail.com> wrote in message news:9247b279-1506-4cbe-a9e8-d993747cac04@w7g2000vbb.googlegroups.com... > 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: Ok. I didn't recognize that as a CFA "primitive" ... I used (S") to implement S" 's run-time. ( ... ) seems to be de facto notation for naming Forth word's run-time... But, I wrote (S") in Forth. Should it have been a "primitive"? > See the Rodriguez article I linked above. I'm sure > you've seen it before. Yes. Sorry, nothing else to add. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-29 08:52 -1000 |
| Message-ID | <jMGdnW2vOd90MyrNnZ2dnUVZ_jGdnZ2d@supernews.com> |
| In reply to | #17668 |
On 11/28/12 11:15 PM, Rod Pemberton wrote: > "Mark Wills" <forthfreak@gmail.com> wrote in message > news:9247b279-1506-4cbe-a9e8-d993747cac04@w7g2000vbb.googlegroups.com... >> 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: > > Ok. I didn't recognize that as a CFA "primitive" ... > > I used (S") to implement S" 's run-time. ( ... ) seems to be de > facto notation for naming Forth word's run-time... But, I wrote > (S") in Forth. Should it have been a "primitive"? Yes, that's a common and helpful naming convention. It's also useful for naming the core functionality of something that has a wrapper (named without the parens) with external stuff such as setup, error checking, or a CATCH. That doesn't necessarily imply that the lower-level word is a "primitive", although factoring it like that makes it easier to recode the low-level word if necessary for performance. Cheers, Elizabeth >> See the Rodriguez article I linked above. I'm sure >> you've seen it before. > > Yes. > > Sorry, nothing else to add. > > > Rod Pemberton > > > -- ================================================== 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 | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-11-28 22:25 -0800 |
| Message-ID | <bc947560-31a1-455d-8061-017332583fbd@nl3g2000pbc.googlegroups.com> |
| In reply to | #17627 |
On Nov 28, 4:58 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > 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. Yes, I used the Laplace transforms. BTW: There is an analogy between slide-rules and calculus. A slide-rule is an analog computer. It theoretically provides infinite precision, but in practice precision depends upon how thin the marks are and how sharp your eyes are, which is good for about 3 digits. The slide-rule has been obsoleted by digital computers which have finite precision (a 64-bit mantissa on the x86), but in practice this precision is more than enough. Calculus is an analog technology. It theoretically provides infinite precision because you get a function which is the integral of the function that you want integrated. In practice, it is a hassle, because you have to use your brain to integrate the function and get the integral. Calculus has been obsoleted by digital computers which just run a numeric integration on the original function. You get the result to a reasonable precision --- without ever obtaining the actual function for the integral, and without ever using your brain at all. I don't think that anybody cares about calculus nowadays. Being able to do integrals is not a practical skill --- it is about as useful as being able to operate a slip-stick --- not something that you want to mention during a job interview. I was interested in calculus at the time because my brother was going to college as a math major. He has long since graduated and forgotten about all that stuff, and I've forgotten about it too --- that was over 20 years ago. Also, I don't really know anything about math beyond calculus, which is freshman-level math --- so I'm not a good candidate for writing a symbolic math program that does anything beyond freshman-level math. That is like standing on the beach with the waves coming up to your knees, as compared to actually swimming in the ocean.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-29 04:12 -0500 |
| Message-ID | <k978km$59i$1@speranza.aioe.org> |
| In reply to | #17659 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:bc947560-31a1-455d-8061-017332583fbd@nl3g2000pbc.googlegroups.com... ... > I don't think that anybody cares about calculus nowadays. Being > able to do integrals is not a practical skill --- it is about > as useful as being able to operate a slip-stick --- not > something that you want to mention during a job interview. It's true that few like doing calculus and true that many never needed it in their careers. But, computers also offer the ability to calculate or compute just about anything, e.g., Wolfram Alpha: http://www.wolframalpha.com/ Personally, I see no point in teaching calculus, taxes, or even cursive writing, but not because they're not important. Latin is important too, if you're say a Bible Scholar. If students spend their time learning calculus, that's time they won't have for other tasks. So, if a computer can do the algebra and calculus, then they can learn or do something more advanced. There is no point in wasting time doing a task that a machine can do for you. This is the computer equivalent of the industrial revolution. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2012-11-28 02:04 -0800 |
| Message-ID | <cd0fa8f5-8e1a-4505-bf4b-cf91ea5dba53@googlegroups.com> |
| In reply to | #17603 |
On Tuesday, November 27, 2012 6:01:26 PM UTC+2, M.R.W Wills wrote: > Very nice write-up here about the Forth virtual machine, complete with > > links to our very own Anton Ertl's pages: > > > > http://www.wordiq.com/definition/Forth_virtual_machine > > > > 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? Adding a level of indirection could lead to easy re-vectoring. Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-28 14:21 +0000 |
| Message-ID | <2012Nov28.152154@mips.complang.tuwien.ac.at> |
| In reply to | #17603 |
Mark Wills <forthfreak@gmail.com> writes:
>Very nice write-up here about the Forth virtual machine, complete with
>links to our very own Anton Ertl's pages:
>
>http://www.wordiq.com/definition/Forth_virtual_machine
>
>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?
You would best ask the author of that page what is meant.
According to Wikipedia:
|A famous aphorism of David Wheeler goes: "All problems in computer
|science can be solved by another level of indirection"
The indirection in ITC was not introduced gratuitiously; in
particular, it allows to treat words more uniformly. I don't know if
that is the flexibility that is meant there, though.
A typical DTC approach in Forth (used in gforth-0.5 on some machines)
would be to emulate ITC by replacing the indirect pointer in the code
field with a jump (or call) to the routine. One loss of flexibility
here is that creating a non-primitive now requires machine-dependent
code.
Another approach is the primitive-centric approach used since
gforth-0.6. There the threaded code contains only primitives and
their immediate arguments, and other words are compiled to a primitive
and an argument, e.g., a call to a colon definition is compiler to the
primitive CALL plus the body address of the colon definition. This
does not require machine-dependent code, but one cannot patch, e.g., a
variable into a deferred word in a way that affects existing uses of
the variable (whereas that works in ITC). Also, COMPILE, now becomes
much more complex.
You might be interested in
@InProceedings{ertl02,
author = {M. Anton Ertl},
title = {Threaded Code Variations and Optimizations (Extended
Version)},
booktitle = {Forth-Tagung 2002},
year = {2002},
address = {Garmisch-Partenkirchen},
url = {http://www.complang.tuwien.ac.at/papers/ertl02.ps.gz},
abstract = {Forth has been traditionally implemented as indirect
threaded code, where the code for non-primitives is
the code-field address of the word. To get the
maximum benefit from combining sequences of
primitives into superinstructions, the code produced
for a non-primitive should be a primitive followed
by a parameter (e.g., \code{lit} \emph{addr} for
variables). This paper takes a look at the steps
from a traditional threaded-code implementation to
superinstructions, and at the size and speed effects
of the various steps.\comment{It also compares these
variants of Gforth to various other Forth
implementations on contemporary machines.} The use
of superinstructions gives speedups of up to a
factor of 2 on large benchmarks on processors with
branch target buffers, but requires more space for
the primitives and the optimization tables, and also
a little more space for the threaded 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] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.forth
csiph-web