Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #31469
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Forth philosophy |
| Date | 2014-06-12 23:15 -0400 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <op.xhdhzzc96zenlw@localhost> (permalink) |
| References | (2 earlier) <0JCdneuVOuwhbgXOnZ2dnUVZ_oadnZ2d@supernews.com> <lnba2h$ecj$1@dont-email.me> <85udnU8yV9DHrgTOnZ2dnUVZ_tadnZ2d@supernews.com> <op.xhcaevla6zenlw@localhost> <5399f3d2$0$6605$9b4e6d93@newsspool4.arcor-online.net> |
On Thu, 12 Jun 2014 14:39:14 -0400, AKK <akk@nospam.org> wrote: > Am 12.06.2014 13:33, schrieb Rod Pemberton: >> [snip] > How did you then handcraft a better 'virtual-identical-to-assembler' > Forth instructions compiler in C? Top Secret! Seriously, I'm not giving all that away, at least not yet. I'll describe alot of what I've done. The inner/address interpreter is coded in C with a few procedures for: NEXT ENTER EXIT . ENTER is sometimes called DOCOL and EXIT is sometimes called SEMIS . NEXT adjusts the working pointer W and instruction pointer IP and calls the CFA. ENTER saves the IP on the return stack, and sets the new IP to W+1. EXIT pops the old IP from the return stack. DOCON DOVAR DODOES etc work the same way as historical Forth does too. EXECUTE is slightly different. Using NEXT in C to EXECUTE would cause a stack leak in C. So, a modified version without the leak is used. It has two stacks, dictionary space, etc too. The inner/address interpreter starts by calling COLD which calls QUERY which calls 'interpreter', the text/outer interpreter, which calls 'compiler' when needed. Originally, 'interpret' called 'interpreter' and 'compiler'. I'm not sure if I need to revert to that in the future. The ordering of the logic was suggested by Andrew Haley (IIRC), and is reverse of the way fig-Forth etc do things. Those Forth words are coded in C (not inline assembly), i.e., 'pre-compiled'. If you looked at the emitted assembly for the C code, the layout will be identical to a Forth coded in assembly, except for placement of the dictionary header, for the primitives, in some cases. Currently, most of the Forth dictionary is coded in Forth which is compiled at run-time by the text/outer intpreter. So, their layout is correct. The Forth interpreter lays down bytes and addresses (not offsets). So, the C data layout issues affect only the low-level primitives since they're "pre-compiled" in C, i.e., hand-coded, just like a word in assembly. But, C can't completely control the layout of data in an object file. Linker script commands are required to do that, but I don't use any of them. I was going for purely ANSI C. Basically, C can *almost* generate any data layout you desire, as long as you know where and when and how to override the type system. This is due in large part because all C objects must map onto an array of characters. Although, you can't completely control ordering of multiple C objects. Nor can you control the alignment of those objects and in-between padding. But, you can control the ordering of objects within single C objects, except for bit fields due to padding. The method I'm currently using can't control the placement of the dictionary header for primitives. This means there is an additional operation in certain words to access the body of the Forth word. Another method, which I haven't attempted yet, should be able to correctly place all data for primitives, body and header, except for the name field. The name field in that case would need a type system override, i.e., cast in C, that isn't allowed by C. If that method works, it would only require an additional fetch for the name field, or perhaps some lower-lower-level nameless primitives, as if defined by :NONAME... That would minimize the differences, probably about as far a C could go, but it's possible that this option is less desirable than the other. I won't know until it's attempted. So, yes, there are some trivial differences in data layout from other Forths. Hopefully, that was informative, but yet a bit too cryptic for now. :-) Rod Pemberton
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Forth philosophy OneArb <o1neeno1@gmail.com> - 2014-06-10 13:23 -0700
Re: Forth philosophy Roger Levy <roger.levy@gmail.com> - 2014-06-10 14:45 -0700
Re: Forth philosophy Elizabeth D Rather <erather@forth.com> - 2014-06-10 12:51 -1000
Re: Forth philosophy hughaguilar96@yahoo.com - 2014-06-10 16:14 -0700
Re: Forth philosophy Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-11 10:03 +0100
Re: Forth philosophy visualforth@rocketmail.com - 2014-06-11 11:11 -0700
Re: Forth philosophy Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-11 21:57 +0100
Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-11 19:30 -0400
Re: Forth philosophy "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 14:26 -1000
Re: Forth philosophy rickman <gnuarm@gmail.com> - 2014-06-12 00:24 -0400
Re: Forth philosophy "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 18:58 -1000
Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:33 -0400
Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-12 20:39 +0200
Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 23:15 -0400
Re: Forth philosophy anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-13 17:29 +0000
Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-14 12:26 +0200
Re: Forth philosophy anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-14 10:59 +0000
Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-14 07:39 -0500
Optimizing C compilers vs. assembly language for Forth interpreters (was: Forth philosophy) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-14 14:40 +0000
Re: Optimizing C compilers vs. assembly language for Forth interpreters Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-14 11:25 -0500
Re: Optimizing C compilers vs. assembly language for Forth interpreters Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-15 23:55 +0200
Re: Forth philosophy albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-14 19:45 +0000
Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-15 13:18 -0500
Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-16 21:14 +0200
Re: Forth philosophy Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-16 22:41 +0200
Re: Forth philosophy AKK <akk@nospam.org> - 2014-06-17 13:32 +0200
Re: Forth philosophy Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-17 15:02 +0200
Re: Forth philosophy mhx@iae.nl - 2014-06-16 13:41 -0700
Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:33 -0400
Re: Forth philosophy barrym95838@yahoo.com - 2014-06-13 21:48 -0700
Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-14 01:01 -0400
Re: Forth philosophy Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-12 03:02 -0500
Re: Forth philosophy albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-12 10:43 +0000
Re: Forth philosophy "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-12 07:32 -0400
csiph-web