_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

No flames here. Inline assembly with ITC or DTC isn't common because, unlike STC, you don't gain much. Using a headerless code definition followed by an ordinary colon definition is often more flexible anyway. Even with something like FIG-Forth, which wasn't designed to use headerless words, it's easy to write a defining word that defines a headerless primitive. Many would argue, however, that inline assembly is a sign that you need to factor your definition. The old "factor, factor, factor" mantra and whatnot.

F-PC (available at www.forth.org and several other sites) uses the names INLINE and END-INLINE to start and end the inline assembly. You just have to keep in mind that it's in interpretation state in between. F-PC is DTC and has separate code and data spaces, so inline assembly compiles to the same thing that a headerless code definition followed by a colon definition would. With ITC, or when the two spaces are not separate, you have to advance the (Forth) IP past the inline assembly at some point before it gets to the NEXT routine, which will be slightly slower and take slightly more space than the headerless code definition with colon definition approach.

I personally don't use inline assembly with DTC or ITC, but I use it all over the place with STC. As a result, I use a "label"-based Forth assembler rather than the more traditional "structured" Forth assembler. In a "structured" assembler, BEGIN, 0<, UNTIL, (or a similar syntax) assembles a BPL that branches to itself. The "label" equivalent is 1 $: BPL 1 $ or a similar syntax (I myself prefer a slightly different, but less common, syntax), which I find much easier to follow, especially when a word has multiple branch instructions. However, if you're only going use inline assembly occasionally (as is more likely to be the case with ITC), then you may find that the structured assembler is sufficient.

Readability is a significant concern with inline assembly, though. I personally find that it's much easier to follow the assembly source code compiled by high-level words (i.e. the JSRs) with inline assembly than the high-level definition (with inline assembly amidst [ and ]) itself. Not quite what I had hoped for, to say the least! The latter can become difficult to follow very, very quickly, unfortunately. Also, some may have trouble switching gears from high-level Forth to assembly back to high-level Forth when trying to comprehend the high-level source of a definition. A few words that abstract implemenation details may prove useful.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The art of factoring (and it is an art) does seem to be a key difference between good Forth code and bad Forth code. I have to admit that most of my better Forth code is factored so that each definition is only one or two lines, even though I never intentionally adhere to that principle ("vertical" code is more my style). But you're right that it can get silly sometimes. I've got one library with a (colon) definition where AND OR is entire sequence between the name (and stack comment) and the semicolon. I don't recall why I factored it that way (I haven't looked at the code in some time), but I do remember that it made sense to me at the time.



Unlike a headerless primitive defining word, BACK_TO_HI_LVL is needed at run time. Since inline assembly is likely to be used only a few times, it might be worth considering whether the space (and speed) overhead of BACK_TO_HI_LVL is really worth it.



Incidentally, while I greatly prefer prefix assemblers to postfix assemblers in Forth, I intended to post the prefix example of a BPL to itself, namely: 1 $: 1 $ BPL, (again using the common syntax).



That wasn't quite what I was getting at. When I write a Forth system in assembly, I like to put the high-level Forth definitions in the comments of the assembly source. To use the FIG-Forth source as an example, I would insert the comment : COUNT ( addr1 --- addr2 n ) DUP 1+ SWAP C@ ; before label L1622 and the comment : MAX ( n1 n2 --- max ) OVER OVER < IF SWAP DROP THEN ; before label L2523. I find it helpful when the definition is long (line after line of .WORD directives), when there are control structures, or if the assembler labels are cryptic (as they often are). And the stack comment is very helpful also.

However, with high-level STC definitions that contain inline assembly, I find that the assembly source is much easier to follow than the high level definition in the comment (though the stack comment is still nice). Even though I'm not trying to be tricky, but just increase the performance of the code, some of the space optimization techniques I described elsewhere (such as the one with ACCEPT) can make the high-level code fairly confusing. Granted, optimization often makes the code less readable, no matter what language is used, but I'd still rather have the code optimized. And it sure doesn't seem to take me long to make the code a lot uglier!



I believe it was Chuck Moore who said that.

The Forth I wrote for the Commodore 64 has a word to go from high level code to assembly called >ASSEM and a word to go from assembly to high level called >FORTH. They do not need paired. A word can start out as a colon definition and go to assembly with >ASSEM and end with a jump to NEXT (or jump to code that jumps or falls through to NEXT) or it can go back to high level with >FORTH. Likewise, a code word can go high level with >FORTH and terminate with ; or go back to assembly with >ASSEM. Here is a short segment of code which uses the C64 REU (ram expansion unit).

It's an easy way to test for the presence of the REU and abort from the code level word. In another example, my version of (TYPE), the vector for TYPE is a code word but I want multitasking support.

Type starts as a colon definition so PAUSE can be called and goes to assembly level where it stays and ends with a jump to NEXT.

cheers,
Jim

I take it "; " terminates the compiler whether under >ASSEM or >FORTH ?

No. My Forth is a Forth-83 standard ITC Forth for the Commodore 64. Semicolon ; terminates high level (colon) definitions. Code definitions are terminated by END-CODE. A code word must have a jump to NEXT or code that jumps to or falls through ( like PUSH and PUT) to NEXT.
>FORTH is an immediate word that can only be used while interpreting, as in compiling a code definition. If STATE is compiling, then >FORTH aborts with the message "EXECUTION ONLY". >FORTH compiles a JSR to the body of (>FORTH) then sets the context vocabulary to the current one and sets the compiling state.
(>FORTH) pulls the JSR's return address off the return stack, increments it and saves it in N, the scratch pad area in zero page, and the Y register. It then pushes IP to the return stack. It takes the address saved in N and the Y register and stores it in IP and jumps to NEXT. Since (>FORTH) performs the function of 'nest', the word transitions from a code word to a high level 'colon definition' without the need to return to the assembly code level. This high level code can now be written to do anything any other high level code can do. It can have multiple EXIT's (EXIT is the word compiled by semicolon ;) or branch into another high level word.
This is in the kernel source.

And this is in the system loader loaded by the kernel.

>ASSEM is an immediate word that can only be used while compiling. If STATE is interpreting, then >ASSEM aborts with the message "COMPILING ONLY". >ASSEM compiles (>ASSEM) into the high level code then sets CONTEXT to the assembler vocabulary and sets the interpreting state.
(>ASSEM) stores IP in N and N+1, then pulls the value off the return stack and stores it in IP, performing an unnest. It then performs an indirect jump through N. Since (>ASSEM) performs the function 'unnest' (what EXIT does), the word transitions from a high level 'colon definition' to a code word without the need to return to high level. This code level word can now be written to do anything any other code word can do.
This is in the kernel source.

And this is in the system loader loaded by the kernel.

Here is my cold start routine for an example. Since this is on a Commodore 64, the system has one line of basic:

The SYS causes a jump to the cold start routine at address 10952, hexadecimal 2AC8.

At start up, BASIC performs a SYS to the Set Interrupt Disable instruction (SEI,) in the cold start routine. Once the system is up and running, the cold start routine can also be called with the word COLD. COLD first saves the block buffers, empties the dictionary to the lesser of its initial and current sizes (saving this value as the new empty point), and closes all files before transitioning to the low level cold start routine.
The Commodore 64 lacks a backslash key so the double slash // is the word to treat the rest of the line as a comment. The funny names like RAMTAS and RESTOR are the names given to Commodore kernel routines in the Commodore 64 Programmer's Reference Guide.
I blanked out the name I'm using for my Forth for now. I'm having trouble thinking of a really good one.
Sorry about the commas at the end of the names of the op codes, I have them there to be compatible with other C64 Forths. Both 64Forth and Blazin' Forth have commas in the op code names. I'd personally like to remove them from my assembler but I hope to make this Forth publicly available one day and I don't know how much grief it would cause someone to rewrite assembly code, by removing all the commas in the opcode names of their source, to try on this Forth.
For another example, here is the full source for (RR/W), the code to access the REU, Commodore's Ram Expansion Unit, as Forth blocks.

There is one caveat when using >FORTH and >ASSEM with control structures which should be obvious, but I'll mention it anyway. If a transition from low to high or high to low occurs in a control structure, the opposite transition must occur before a matching control structure word is used. I don't have actual examples other than the IF, ELIF, THEN, control block in the code above for the ram expander, so here is some pseudo-code:



Cheers,
Jim

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks, but I can't really take credit for the names. I saw in online documentation for Mosaic Forth ( I was trying to find more information on Forth) it had the names >ASSM and >FORTH. While I agree about standard names in general, long ago I renamed UNDO to UNLOOP, I see a problem with renaming >ASSEM and >FORTH. If I rename >ASSEM to INLINE and >FORTH to END-INLINE it looks fine with words that start high level, transition to assembly, then back to high level.

It looks a little strange with a word that starts high level then goes to assembly and stays there.

And looks really strange with a word that starts as a code definition, then transitions to high level then back.

I'm not trying to be difficult but it seems that >ASSEM and >FORTH aren't really like INLINE and END-INLINE. It looks as though INLINE and END-INLINE are meant to be paired in that order. >ASSEM and >FORTH don't need to be paired. >ASSEM performs an unnest, like EXIT and >FORTH performs a nest, like do-colon. As my definition of (TYPE) shows, they both don't need to be present in a definition.
[Edit: fixed a typo]

Actually, at the time I wrote >ASSEM and >FORTH, I'd forgotten that the Mosaic Industries version, >ASSM, didn't have an 'E' in the name.

If the function is different, and a major, popular Forth was already using >ASSEM and >FORTH, then I'd say go ahead and keep those names. I just haven't heard of them before. The way I did INLINE and END_INLINE, they don't particularly need to be paired. I also don't use vocabularies though, which might make a difference. There's no conflict between assembly language and Forth words though, because for example AND in assembly language is never just AND; instead, the addressing mode goes with it, like AND#, AND_ZP, etc.. Similarly, there's no conflict with the # of "sharp" (in Forth) and the # of "immediate" in assembly. So I would write for example AND# FOOBAR , (the comma being part of it, for '816 with the accum in 16-bit mode) which I think is a lot more readable than FOOBAR # AND , and there's no parsing because all AND# does is lay down the op code. It's up to the programmer to comma-in the operand (if any). (I've said this in previous posts, but you're a welcome new member who probably hasn't read all the archives yet. )

And you posted this while I was writing:

If they were going to leave out more letters, too bad they didn't shorten it to >ASM which might be even more clear because of the common use of those three letters for "assembly." "ASSM" could look like "assimilate" or any of a lot of other things.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Although I haven't read all the archives, not even close, I do remember reading about your assembler. From my code you can probably tell that I actually prefer the FOOBAR # LDA, approach. Maybe I've been using it so long that It's what I'm comfortable with.

I ended up sneaking assembly into an Forth word for special cycle-count testing of Tali Forth 2 (an STC Forth). It was done to reduce the overhead of "stopwatching" a word. The simulator this runs in has a (virtual) stopwatch that is started by accessing $F006, stopped by accessing $F007, and the result (as a double-word with the bytes in correct 6502 forth order) shows up at $F008-$F00B. I use self-modifying code that replaces the address of the JSR between starting and stopping the virtual stopwatch. Processing the results is done in Forth. I don't have a Forth assembler loaded, so I just poked the opcodes into the word.


To test a word, I just put some test arguments for it on the stack (if it needs them), use ' to get the XT of the word I want to test, and then run my test. Then I clean up the stack. I don't check the results of the operation because the test suite does that elsewhere. This is just to get an idea of how many CPU cycles each word takes. A sample test for DUP might look like:

When run, that looks like:

Well, that depends. What about the case with inline high level code in an assembly ( code ) definition? My Forth is an ITC Forth for the C64 and has blocks. As I've mentioned elsewhere:

It's been my experience that when BLOCK is called, it's usually called quite a few times with the same block number before a different block is requested. I thought,"Wouldn't it be nice if BLOCK were a code definition for all the times where it only has to replace the block number with an address?" Using >FORTH makes it easy to write BLOCK as a code definition if the requested block is the most recently used ( accessed ), yet be able to go to high level code for everything else.
Being able to ABORT or ABORT" from a code definition without the need to pass an error flag to a high level "wrapper word" is handy. I realize that some code words return a flag so the high level routine calling it can decide what to do. FIND comes to mind. If the word is not found in the CONTEXT vocabulary, search the CURRENT one, but I'm refering to a case where if the word were written in high level Forth, it would abort on an error. It would be nice to rewrite that word as a code word for speed, but it needs to abort on an error. It can by including inline high level forth code. It's also an easy way to get the coldstart and warmstart routines running the quit loop, just write it as a transition to high level:

I've found >FORTH and >ASSEM so useful that I've included them in my assembler and the primitives, (>FORTH) and (>ASSEM) are part of my Forth kernel. Since I already have them, including inline assembly in high level code doesn't cost anything extra. I rewrote # so it has inline assembly. the resulting word was four bytes smaller ( on my ITC Forth ) and the pictured numeric output words were a bit faster. When I have more time, I'll run some timing tests to get an idea of how much faster.
Anyway, I hope this gives food for thought.

Cheers,
Jim