インタプリタとコンパイラの中間的手法の1つとして、ソースコードを最適化された抽象構文木 (AST) に変換し、その木構造にしたがってプログラムを実行するか、実行時コンパイラでの機械語コード生成に使用する方法がある。この方式では各文を1回だけ構文解析する必要がある。バイトコードに比べると、ASTではプログラムの全体的構造や文と文の関係を保持でき（それらはバイトコードでは失われる）、圧縮するとさらにコンパクトな表現になる。そのため、実行時コンパイラにとってはバイトコードよりもASTの方が優れた中間表現だとして提案されてきた。また、実行時の解析もより優れたものにできる。しかし、ASTはバイトコードよりも冗長であるため、インタプリタとしてはオーバーヘッドが大きくなるという問題がある。CRuby の場合は、1.8までは構文木インタプリタであったが、1.9では（開発中には YARV と呼ばれていた）バイトコードインタプリタに入れ替えられ、性能が向上した。
ソースコードを実行可能な形にするには、まず、ソースコードを構文木に変換する必要がある。構文木のまま、インタプリタ型の処理系で実行する処理系もあるが、構文木をさらに、中間コード（バイトコードなど）などの中間表現に変換してから実行する物もある。中間コードをバイトコードと呼んでいる処理系ではそのインタプリタをバイトコードインタプリタと呼ぶ。Java や .NET Framework のように、中間コードの仕様を公開しファイルに書き出すものもあるし、仕様は公開せず処理系内部だけで使用するものもある。動的コンパイルを使っているインタプリタは、内部で実機の機械語に変換し実行する。インタプリタとコンパイラの間には様々な中間的実装が存在し、それぞれにプログラム実行前に行われる解析の度合いが異なる。例えば Emacs Lisp はバイトコードにコンパイルされ、LISP のソースを高度に圧縮し最適化した表現にしているが、それは機械語コードではない（したがって特定のプラットフォームに依存しない）。この「コンパイル」されたコードを解釈するのがバイトコードインタプリタである（それ自体は C で書かれている）。この場合のコンパイルされたコードは仮想機械の機械語コードであり、仮想機械はハードウェアで実装されておらず、バイトコードインタプリタとして実装されている。同様の手法は Open Firmware システムで使われている Forth コードでも使われている。ソース言語は「Fコード」（バイトコードの一種）にコンパイルされ、それを仮想機械が解釈実行する。他にPコードマシンなどがある。コントロール・テーブルはコンパイラを通さなくとも生成でき、バイトコードインタプリタと同様の方法でカスタマイズされたインタプリタでの適切なアルゴリズム的制御構造を記述できる。
それ自体はインタプリタの手法とも言えるしコンパイラの手法とも言える。そのどちらと言うよりも、中間表現の1種類というべきかもしれない。仮想関数テーブルやテーブルジャンプによるフロー制御に似ていなくもない。スレッデッドコードは、呼び出されるべきサブルーチンのアドレスのみが順番に羅列されたものである。「直接スレッディング」の場合は、そのアドレスが指す先は機械語のサブルーチンである。他にもいくつかのバリエーションがある。「サブルーチン・スレッディング」は最も違うタイプのバリエーションで、アドレスのみではなく、機械語のCALL命令として羅列するので、ハードウェアのプロセッサで直接実行できる。これは実行のオーバーヘッドは極小だが、メモリ効率は悪い。サブルーチン・スレッディング以外のスレッデッドコードは、きわめて単純なインタプリタで実行できる。Forthでは「内部インタプリタ」と呼んでいる（これは、Forth言語自体を実装しているインタプリタである「外部インタプリタ」と対になっている）。
コンパイラは一般にソースコードを特定のプロセッサアーキテクチャの機械語命令列に変換するので、生成されるプログラムは特定のアーキテクチャのプロセッサでしか動かない。この変換は開発者の環境で一度だけ行われ、そのバイナリが配布され、ユーザー側では変換を行う必要がない。クロスコンパイラを使えば、他のプロセッサアーキテクチャ向けのバイナリを生成することができる。インタプリタの場合、ソースコードを配布できる。その変換はユーザー側で行う必要があるが、特定のアーキテクチャに依存しないプログラムの配布が可能である。ただし、その場合ユーザーのマシン上に適当なインタプリタが実装されていなければならない。インタプリタとソースコードを同時に提供する必要があるなら、単に実行ファイルを配布した場合よりインストールが全体として複雑化することもある。インタプリタ用コードは人間が容易に読むことができるため、著作権保護の観点から問題があるとする見方もある。しかし、そのための様々な暗号化や難読化のシステムも存在する。バイトコードのような中間コードを配布する場合、ある程度は難読化と同様の効果があるが、バイトコードを逆コンパイラあるいは逆アセンブラでデコードすることも可能である。抗逆コンパイル性のある難読化を考慮したバイトコードとする設計もありうる。
本型は「高速戦艦」とも呼ぶべき戦艦であり、八八艦隊計画の長門型に次ぐ3番艦、4番艦として計画された。先行2隻（長門、陸奥）では完全に取り入れる事が出来無かったユトランド沖海戦の戦訓を長門型以上に徹底して取り入れるため、長門型で採用された集中防御方式をさらに強化している。長門型では舷側の装甲帯の上部装甲はより薄くなっており、またその装甲は舷側に垂直に取り付けられていた。これに対し加賀型では舷側の装甲帯の装甲厚（10-11吋/インチ）は上部〜下部ともに完全に同一になっている。また、一部の装甲を傾斜式にするなどして更なる防御力の強化を図っている。この時点で、日本海軍の防御設計は従来の英国式のものから完全に脱却した。さらに、日本海軍の戦艦で初めて煙路防御を施している。砲塔12インチ・砲塔天井6インチ、遠距離砲戦で重要となる水平防御の為に甲板に張られた装甲は4インチもあり、建造時は世界最強の防御を持っていた。ちなみに当時のアメリカの最新鋭戦艦の水平防御装甲厚は3.5インチである。水線下には、日本海軍艦艇初のバルジを装着した。攻撃力の面では、長門型が41センチ砲4基8門であったのに対して、1基砲塔数が増加して5基10門となり、世界最大の主砲を10門搭載する重武装となっている。長門型の砲塔と形状が若干異なり、仰角は増しているが（長門型は仰角30度俯角5度、加賀型は仰角35度俯角3度）、砲塔の側面装甲は若干減らされている。速力の面では、長門型より新式で91,000馬力を発揮する新式機関を搭載した。これにより長門型より船体規模、排水量が大幅に増加して39,979トンになったにも関わらず、長門型の21基より少ない12基で26.5ktの高速を維持できる見込みであった。缶数が減少した事により、煙突は長門型の2本から1本になった。