Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: Forth philosophy Date: Thu, 12 Jun 2014 23:15:25 -0400 Organization: Aioe.org NNTP Server Lines: 68 Message-ID: References: <0JCdneuVOuwhbgXOnZ2dnUVZ_oadnZ2d@supernews.com> <85udnU8yV9DHrgTOnZ2dnUVZ_tadnZ2d@supernews.com> <5399f3d2$0$6605$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:31469 On Thu, 12 Jun 2014 14:39:14 -0400, AKK 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