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