Kawari Source Outline

• Uses C++, STL
• Compatible with SJIS only. Convert to wstring and process when necessary. It's pretty bad.
• There is evidence that an attempt was made to support Python and Java in the Saori section.
• Multiple Kawari engines can be generated within a single process.

Source Configuration

libkawari/

Kawari core. TKawariEngine manages everything.

Dictionary data structure

The data structure that manages all data by converting it into a 32-bit ID for each fragment is one of Kawari's greatest features. Since the same ID is always given to the same data, various calculations at runtime are extremely fast, but the cost of reading the data is high (the cost of storing a single word is proportional to the search cost of std::map).

The Kawari data structure (dictionary) is a String- map (actually ID-), and key strings are managed separately as a tree structure with dots ('.') as delimiters. This is Kawari's only data structure/data space. In other words, the data (KIS code) can only be retrieved by searching using the key string (actually the key ID) instead of the normally used memory address.

In addition to a static global dictionary that is prepared for each Kawari engine, there are also dictionaries that are dynamically created and disposed of as so-called stack frames used for history references and temporary variables. In Kawari, this stack frame dictionary is called a "context."

In addition, once a string was ID'd, it was never deleted again up until Kawari 7, but Garbage Collection (GC) was introduced in Kawari 8. At the end of intermediate code evaluation, GC tests for IDs that have been deleted from the dictionary at least once during the evaluation. Because of the nature of equal data being the same ID, some IDs are referenced by more than one key, so all IDs to be deleted are checked to see if they are referenced by any other key.

wordcollection: Data Identification
kawari_ns: Map + tree structure key
kawari_dict: Global dictionary + context management. One per engine.

Parser, compiler

kawari_crypt: Encryption related
kawari_lexer: Character analysis. Difficult to separate modes.
kawari_compiler: Parsing. Syntax tree construction.
(kawari_engine): Top-level routines for dictionary reading function (to be changed)

Intermediate code object

Most of the syntax commands are parsed at runtime and are therefore described in kawari_code.

KIS and so-called dialogues and words are treated in the same way as KIS intermediate code objects. Normal strings are "intermediate codes that return strings without side effects." KIS user functions are stored in ordinary entries with a special prefix in the function name. Therefore, although the dictionary notation and invocation methods are different, scripts and script scripts have the same storage format inside Hwashi.

kawari_code: Script, entry array call
kawari_codeexpr: Arithmetic expression
kawari_codeset: Entry call, set operation
kawari_codekis: KIS syntax (if only)

Execution

Although it is called a VM, it executes the syntax tree as is, so it is not a VM at all. The only thing the VM does is create and manage the context at the start of evaluation and when calling user functions. Even that consumes the native stack and calls it as is, so it can be said that the KIS stack is not properly managed.

TKawariEngine is the "Kawari Engine" object and is responsible for generating and managing other modules. Many of the KIS commands access Kawari functionality through Engine methods. If detailed control is required, obtain each module object from the Engine and manipulate it.

kawari_vm: Intermediate code execution
kawari_engine: Kawari engine

Log resources

kawari_log: Logger
kawari_rc: Resources (Error messages, etc., prepared for each language)
kawari_version: Version, license message

kis/

Implementation of built-in KIS commands.

saori/

Saori client (side that calls Saori) implementation. It is written in a framework style. 。

saori

Alias-module path correspondence management. Dynamic generation (load) management by load type (such as noresident).

saori_module

Communication interface and starting point for module generation using the Factory pattern. It becomes a branching point to call various types of Saori I/F.

saori_unique

Decorator for module generation Factory that prevents multiple startup of modules. Counts the number of active binds and unloads when it reaches 0. Currently spawns one per engine instead of per process (potential bug).

saori_native

Generation and communication of shared library format Saori.

saori_java

Generation and communication of Java format Saori. Compilation environment not yet prepared (JVM export lib required).

saori_python

Generation and communication of Python script format Saori. Unfinished.

include/

API specifications exported by Kawari SHIORI.

shiori/

Kawari's SHIORI interface implementation.

misc/

Utility

tool/

External tools such as Kosui