stanford-oval/wikipedia huggingface dataset:
グラフ作成ソフト
フリーで利用できるグラフ作成ソフト

AV似非 - 3次元データをスカラー量の分布図、矢印によるベクトル図、等高線図などで描く事を目的としたソフト。
Calc.exe - Windows 付属の電卓。Windows 10 よりグラフが描けるようになった。
FreeMat - 数値解析ソフト。
FunctionView(公式サイト) - グラフをアニメーション表示できる関数グラフ作成ソフト。
GeoGebra - 動的な数学ソフトウェア。
GMT - 主に地図を描画するためのコマンド群であるが、グラフも描ける。
Gnumeric - 表計算ソフト。GNOMEデスクトップの一部。
GNU Octave - 数値解析ソフト。
Gnuplot - コマンド入力型の古典的なグラフ作成ソフト。
GrADS（英語版）
GRAPES - 主に学校教育で学習するための関数を作図するソフト。
Graphics Layout Engine（英語版）
Grace_(plotting_tool)（英語版）
Graph Mate - 科学技術用グラフ作成&データ処理ソフト。
Graphviz - DOT言語用のツールパッケージ。
gretl - 統計解析ソフトウェア。
JFreeChart - Javaで記述されたグラフライブラリ。
jHepWork（英語版） - デスクトップアプリ。
JMathLib - Octave、SciLab、Freemat、Matlabなどのクローンソフト.
KChart - 表計算ソフト。KDE環境でのオフィスソフト(Calligra Suite)の構成要素。
LabPlot（英語版）
LibreOffice Calc - 表計算ソフト。
Maxima - 数式処理システム。
Ngraph(公式サイト) - 2次元データのグラフ描画ソフト。WindowsやX11環境で動作する。最終更新 2010年6月5日 Ver.6.03.53
Ngraph-gtk(公式サイト) - デスクトップアプリ。NgraphのGTK版。
ParaView - データ分析と可視化のためのアプリケーション。
PGPLOT - グラフィックサブルーチンライブラリ。
ploticus（英語版） -統計的な処理が可能。曲線適合化、線形回帰計算、ピアソン相関係数、頻度分布計算の機能を備えている。
PLplot（英語版） - ライブラリ。
PrimMath - デスクトップアプリ。グラフ作成のほか、表計算、数値計算、独自スクリプト言語によるプログラミングができる。
PSPP - 統計解析ソフト。
QtiPlot（英語版） - デスクトップアプリ。OriginやSigmaPlotの代替。
RINEARN Graph 3D(公式サイト) - 表計算ソフトや数値計算プログラミングなどで作成されたファイルから3次元グラフを作成できる、インストール不要のグラフソフト。
ROOT - データ解析環境、ライブラリ。
RRDtool（英語版）
Samurai Graph(公式サイト) - デスクトップアプリ。2次元データのグラフ描画ソフト。EMF, SVG他出力に対応。理化学研究所脳科学総合研究センターのプロジェクト。最終更新 2010年11月23日 Ver.2.0.0
SciDAVis（英語版） - デスクトップアプリ。Originの代替。
SciGraphica(公式サイト) - Originに似たソフトをUNIX上でフリーに作成しようというプロジェクト。最終更新 2005年6月23日 Ver.2.1.0
Scilab - 互換性はないがMATLABクローンの数値解析ソフト。
Teechart
Veusz - Windows, MacOS, Linuxに対応したクロスプラットフォームアプリ。GUI・CUI(Python)両方での操作が可能。出力形式はPNG, JPEG, BMP, TIFF, XPM, SVG, EMF, PDF, PS, EPS。
Visifire（英語版） - Silverlightによるデータ可視化コンポーネント。
VisIt（英語版） - デスクトップアプリ。
WordGraph(公式サイト) - タブインデントで記述されたテキストの構造を解析し、グラフ描画するソフト。最終更新 2010年3月21日 Ver1.0.0
XYGrapher(公式サイト) - デスクトップアプリ。散布図や等値線図の作成ソフト。Windows用に加えLinux版も配布している。最終更新 2011年12月15日 Ver3.0
汎用プログラミング言語・ライブラリ

汎用プログラミング言語の中でも、特にグラフ作成用途として用いられる機会が多いもの
R言語 - 統計解析向けに作られたプログラミング言語。データ視覚化パッケージであるggplot2を用いることで高度なグラフ作成が可能。
Python - NumPy, SciPy, SymPyなどの高速・多機能な数値計算ライブラリの存在により、科学技術計算とその可視化のために頻繁に用いられる。グラフ化のための著名なライブラリとしてはMatplotlibやPlotly（英語版）がある。
Julia - 一般的な動的プログラミング言語と比べて高い実行速度で知られる。Plots等の可視化パッケージのほかに、R言語やPythonのライブラリを呼び出すことも可能。
アセンブリ言語

他のプログラミング言語
■カテゴリ / ■テンプレート
モトローラ MC6800 のアセンブリ言語のソースコード
アセンブリ言語（アセンブリげんご、英: assembly language、アセンブリ）はビット列命令に対応した文字列命令を利用する低水準プログラミング言語の総称である。
アセンブラ（英: Assembler）またはアセンブラ言語（英: Assembler Language）とも呼ばれる。
概要

プロセッサは機械語プログラムを直接読み取り実行する。しかし人間にとってビット列は直観的に理解しづらいため、機械語コーディングは容易でない。これを解決するために、ビット列に対応する文字列命令（ニーモニック）を利用するプログラミング言語の総称がアセンブリ言語である。
アセンブリ言語を用いることで、機械語相当の低水準なコードをより直観的に記述できる。高度なアセンブリ言語ではアセンブラに対する命令（疑似命令）やマクロを用いて、より抽象的な記述が可能である。パイプライン処理などを最適化するために命令順序を入れ替えたり、ラベルの位置関係によってアドレッシングモードを最適化するアセンブラもあり、必ずしもソーステキストの記述とアセンブルの結果が直接対応するとは限らない。
アセンブリ言語は機械語と強く結びついているため、各プロセッサ向けに仕様の異なる様々な（具体的な）アセンブリ言語が存在する（「アセンブリ言語」は総称である）。同じ命令セットに対しても複数のアセンブリ言語が存在しうる（例: GNUアセンブラのgasのインテルプロセッサ用）。
アセンブリ言語の基本文法として、1つの命令は1つのニーモニックと0個以上のオペランドからなる。プログラム全体はニーモニック/オペランド列、ディレクティブや擬似命令と呼ばれるメタな文、コメント、データで構成されている。通常の文はオペコードのニーモニックで始まり、パラメータ（データ、引数）のリストがそれに続く。多くのアセンブリ言語はオペランドのアドレスや定数をラベル・シンボルで記述できハードコーディングを避けられる。
基本文法

アセンブラの開発者によって用語の使い方に大きな差異があり、文の分類などが異なる。例えば、マシンのニーモニックや拡張ニーモニック以外は全て擬似命令と呼ぶ場合もある。典型的なアセンブリ言語は、プログラムの操作の定義に使われる命令文をニーモニック、データセクション、アセンブリディレクティブの3種類に分類する。
基本文法 > ニーモニック

ニーモニック（英: mnemonic）は処理内容に応じて各機械語命令に与えられた文字列・命令語である。機械語のオペコードに相当する。
ビット列である機械語はその処理が直観的にわからないため、機械語コーディングは容易でない。人間がより容易に機械語と同等なコードを書くため、ビット列を意味ある文字列で表現するニーモニックが発明された。例えばX64機械語 0x05 は「整数の加算」を意味するのでニーモニック ADD を対応させる。個々の機械語命令には少なくとも1つのニーモニックが対応する。
拡張ニーモニックは命令の特殊な用途をサポートするのに使われることが多く、本来の命令の名称からはその用途が連想できないときに使うことが多い。例えば、多くのCPUは明示的にNOP命令を用意していないが、その用途に使える命令は存在する。8086ではxchg ax,axという命令がnopとして使えるので、アセンブリ言語でnopを記述すると xchg ax,ax という命令に変換される。逆アセンブラにもこのあたりを認識し、xchg ax,axをnopに変換するものがある。同様にIBMのSystem/360とSystem/370のアセンブラでは、拡張ニーモニックNOPとNOPRを使用し、それぞれBCとBCRのマスク0の命令に変換する。SPARCアーキテクチャでは、拡張ニーモニックをsynthetic instructionsと呼んでいる。
命令は一般に「オペコード」と0以上の「オペランド」で構成される。多くの命令は1つまたは2つの値を参照する。オペランドには即値（命令内に置かれる値）、レジスタ（暗黙のうちに使用される場合もある）、記憶装置内のデータの位置を示すアドレスなどがある。「拡張ニーモニック」はオペコードと特定オペランドの組合せを表すのに使われることが多い。例えば、System/360では、BC命令にマスク15を組み合わせたものがB、BC命令にマスク0を組み合わせたものがNOPという拡張ニーモニックで表される。オペランドの順序（例: ソースとディスティネーションの前後）は言語に依る。
基本文法 > オペランド

オペランド（英: operand、被演算子）は命令の対象・引数である。1つの命令では、ニーモニックに続き0個以上のオペランドが記述される。オペランドにはソースとデスティネーションの二種類があり、データとして読み取られるのがソースで、オペコードで示された命令の実行結果が格納されるのがデスティネーションである。ソースには定数・レジスタ・メモリのいずれか、デスティネーションにはレジスタ・メモリのいずれかを指定する。
基本文法 > オペランド > データセクション

データと変数を保持するデータ要素を定義するのに使われる命令文がある。データの型、長さ、境界（アライメント）を定義する。また、そのデータがプログラム外部（別ファイルでアセンブルされたプログラム）からも利用可能なのか、それともデータセクションを定義したプログラム内でのみ使用可能なのかも定義できる。一部のアセンブラはこれを擬似命令に分類している。
基本文法 > アセンブリディレクティブ

→「ディレクティブ」も参照
アセンブリディレクティブは、擬似命令とも呼ばれ、アセンブラがアセンブリ実施中に実行すべき命令となっている。プログラマが入力するパラメータによって、異なった形でアセンブルが行われるよう指示することができる。また、プログラムの見た目を操作して、可読性と保守性を向上させるのにも使われる。例えば、記憶装置の領域を予約し、その初期内容を指定するディレクティブなどがある。ディレクティブの名称はドットで始まることが多く、それによって通常のニーモニックと区別している。
擬似オペコード(pseudo-opcode)と言った場合、オブジェクトコードを実際に生成するディレクティブのみを指すこともある。
基本文法 > アセンブリディレクティブ > ラベル/シンボル

シンボリックアセンブラでは、任意の名前（ラベルまたはシンボル）とメモリ位置を対応付けることができる。通常、定数や変数に名前をつけることができ、命令文ではそれらの位置を名前で参照できる。実行コードではサブルーチンのエントリポイントと名前を関連付け、サブルーチンを名前で呼び出すことができる。サブルーチン内では、分岐命令の分岐先をラベルで示すことができる。一部のアセンブラは「ローカルシンボル」をサポートしており、通常のシンボルとは語彙的に区別する（例えば、"10$"を分岐先に使用する、など）。
一部のアセンブラは柔軟なシンボル管理を提供しており、複数の名前空間を管理したり、データ構造内のオフセットを自動的に計算したり、リテラル値やアセンブラが実施した単純な計算結果を参照するラベルを割り当てたりすることができる。ラベルは定数や変数をリロケータブルなアドレスで初期化するのにも使える。
例

x86/IA-32プロセッサにおいて8ビット即値をレジスタに入れる命令を例にとる。
この命令のバイナリコードは 10110 で、その後に3ビットのレジスタを指定する識別子が続く。AL レジスタの識別子は 000 なので、次に示す機械語は AL レジスタに 01100001 というデータをロードする。
10110000 01100001
このバイナリコードを人間が読みやすいように十六進法で表現すると次のようになる。
B0 61
ここで、B0は「ALに後続の値をコピーする」ことを意味し、61は01100001を十六進法で表したもの（十進法では97）である。インテルのアセンブリ言語では、この種の命令に MOV というニーモニックを割り当てており、セミコロン以下に説明的コメントを添えたアセンブリ言語での表現は次のようになる。
MOV AL, 61h       ; Load AL with 97 decimal (61 hex)
この場合、定数61Hがソース、レジスタALがデスティネーションに該当し、命令が実行されると、定数61Hが、レジスタALに単純に格納される。これが人間にとってはさらに読みやすく覚えやすい。
前述のインテルの MOV のようにデータの転送の多くを同一の命令あるいはニーモニックとする場合もあれば、データのコピー/移動の方向などによって別々の命令あるいはニーモニックとする場合もある（「メモリからレジスタへの移動」を L、「レジスタからメモリへの移動」を ST、「レジスタからレジスタへの移動」を LR、「即値をメモリへ移動」を MVI など）。（この段落では命令セットの設計の話とアセンブリ言語の話を一緒にしている）
インテルのオペコード 10110000(B0)は8ビットの値を AL レジスタにコピーするが、10110001(B1)はCLレジスタにコピーし、10110010(B2)は DL レジスタにコピーする。これらをアセンブリ言語で表現すると次のようになる。
MOV AL, 1h        ; Load AL with immediate value 1
MOV CL, 2h        ; Load CL with immediate value 2
MOV DL, 3h        ; Load DL with immediate value 3
MOVの構文には次の例のようにさらに複雑なものもある。
MOV EAX, [EBX]	  ; Move the 4 bytes in memory at the address contained in EBX into EAX
MOV [ESI+EAX], CL ; Move the contents of CL into the byte at address ESI+EAX
MOVというニーモニックを使った文は、その内容によってアセンブラが88-8E、A0-A3、B0-B8、C6、C7のいずれかのオペコードに変換するので、プログラマはオペコードを知る必要がないし、オペコードを覚える必要もない。
高級言語との違い

アセンブリ言語は低水準プログラミング言語であり、C言語などの高級言語より抽象度が低い。すなわち言語機能（構文や型）が少ない。次の表は「基本的なアセンブリ言語」と高級言語の間にある言語機能差である。
|  | アセンブラ | 高級言語 |
| --- | --- | --- |
| レジスタ | ✔ | - |
| ジャンプ命令 | ✔ | △ |
| 制御構造 | - | ✔ |
| 構造体 | - | ✔ |
| 関数 | - | ✔ |
コメント: ✔
この差はあくまで言語機能の差である。「高級言語でのみ可能、アセンブリ言語では不可」という意味ではない。例えばアセンブリ言語に関数構文は存在しないが関数に相当するパターンが存在する（関数プロローグ・エピローグ（英語版））。より正確な言い方をすれば、アセンブラで頻出するパターンを1つの機能として言語仕様に組み込んで抽象度を上げていった言語が高級言語である。
高水準文法

より抽象化され少ないコード量でアセンブラを書くために様々な高水準文法がアセンブリ言語に導入されてきた。現在では高水準化のメインストリームは高級言語に移った一方、目的に応じてアセンブリ言語を選択するユーザー向けに高機能なアセンブリ言語の開発も続いている。
高水準文法 > マクロ

→「マクロ (コンピュータ用語)」も参照
アセンブリ言語においてもマクロが利用される。一般的なマクロと同様、高度なアセンブラマクロでは制御構文導入・引数展開・ユーザー定義マクロ適用などが可能である。文字列であるオペコード・ニーモニックはマクロの対象となるため、これを利用して疑似ニーモニックによる記述も可能になる。
例えば、一部のZ80用アセンブラでは、ld hl,bc というマクロ命令を ld l,c と ld h,b という2命令に展開する。メインフレームの時代には、マクロは特定顧客の大規模ソフトウェアシステムのカスタマイズや、メーカーのオペレーティングシステムを顧客の要望に合わせた特注版にするのに使われていた。IBMの VM/CMS、リアルタイムトランザクション処理用アドオン、CICS、ACP（英語版）/TPFなどで使われてきた。
高水準文法 > 制御構造

構造化プログラミングの要素を取り入れたアセンブラもある。最初期には "Concept-14 macro set" がSystem/360のマクロアセンブラにIF/ELSE/ENDIFなどの制御構造を導入した。また8080/Z80プロセッサ向けの A-natural ではブロック構造や命令実行順序の制御が採用された。
また構造化プログラミングとは若干異なるが、キャリーラボはBASIC風の文法のアセンブリ言語 BASE を開発した。Z80用のBASE-80とMC6809用のBASE-09がある。BASEの表記例は下記の通り（BASE-09）。
S[A,B,X,U
A=$80
A=A+$C0
S]A,B,X,U,PC
上記の記述は下記のアセンブラ表記に対応する。
PSHS A,B,X,U
LDA #$80
ADDA #$C0
PULS A,B,X,U,PC
アセンブラ

アセンブル（英: assemble）はアセンブリ言語で書かれたプログラムから機械語で書かれたオブジェクトコードへの変換である。具体的には、ニーモニックをオペコードに変換しシンボル名をメモリ位置や他の実体に変換する。
アセンブルは比較的単純な規則からなるため、人の手でも実行できる（ハンドアセンブル）。単純な作業を効率良くミス無く行うのはプログラムの得意分野であり、そのようなソフトウェアが開発された。このアセンブリをおこなうプログラムをアセンブラ（英: assembler）という。初期にはアセンブリプログラムとも呼ばれた。
シンボル名による参照の利用はアセンブラの重要な機能であり、面倒な計算やプログラム修正に伴うアドレスの更新の手間を省くことができる。また、オブジェクトコードを生成する際、ローダ用情報も併せて生成するアセンブラもある。マクロを含むアセンブリ言語に対応している場合、処理系にはm4のような汎用プロセッサあるいはプロセッサ内蔵アセンブラ（マクロアセンブラ）が利用される。ポリモーフィズム、継承などをもつ高水準アセンブリ言語に対応したアセンブラは高水準アセンブラ（英語版）と呼ばれる。
動作プラットフォーム以外のターゲットプラットフォームを選択できるアセンブラはクロスアセンブラとも呼ばれる（参考: クロスコンパイラ）。メタアセンブラは、アセンブリ言語の文法や意味論を記述したものを入力とし、その言語のためのアセンブラを出力するプログラムである。
逆方向の変換、すなわちオブジェクトコードのアセンブリ言語化をおこなうプログラムを逆アセンブラという。
アセンブラ > 分類

アセンブラは様々な観点から分類できる。パス回数（アセンブル時のソースファイル走査回数）の観点ではワンパスアセンブラとマルチパスアセンブラに分類できる。
どちらの場合も、アセンブラは最初のパスで各命令のサイズを確定させる必要があり、それによって後に出現するシンボルのアドレスを計算する。命令のサイズは後から定義されるオペランドの型や距離に依存することがあるため、アセンブラは最初のパスでは悲観的な見積もりをし、必要に応じてその後のパスまたは errata にて1つ以上のNOP命令（何もしない命令）を挿入してすき間を埋める必要がある。最適化を行うアセンブラでは、最初の悲観的コードをその後のパスで稠密なコードに書き換えてアドレスの再計算を行うことがある。
もともとワンパスアセンブラは高速であるためよく使われていた。マルチパス動作をするには、磁気テープを巻き戻したりパンチカードのデッキをセットし直して読み込む必要があったためである。現代のコンピュータではマルチパスであってもそのような遅延は生じない。マルチパスアセンブラは errata がないため、リンク処理（アセンブラが直接実行コードを生成する場合はローダの処理）が高速化される。
アセンブラ > 主なアセンブラ

IBM High Level Assembler (HLASM) - IBM系メインフレーム用のアセンブラ。
PDP-8のアセンブリ言語 - PAL-III (Program Assembly Language III)
CAP-X - CASL 以前に情報処理技術者試験で使われていたアセンブリ言語
CASL - 情報処理技術者試験（基本情報技術者試験）用に作られたアセンブリ言語。同時に定義されているペーパーマシンCOMET用
as - UNIX用のアセンブラ
GNUアセンブラ (gas) - GNUプロジェクトが開発する、x86、680x0、SPARC、VAXなどの各種CPU用のアセンブラ
Microsoft Macro Assembler (MASM) - インテルのx86 CPU用にマイクロソフトが開発したアセンブラ
Netwide Assembler (nasm) - MASMと互換性の高いx86 CPU用アセンブラ
Turbo Assembler (TASM) - ボーランドが開発していた、MASMと互換性の高いx86 CPU用アセンブラ
MIXAL - ドナルド・クヌースが考案したペーパーマシンMIX用。また後継ペーパーマシンMMIX用のMMIXALも存在する
A-natural - Whitesmiths Ltd. が開発、8080/Z80プロセッサ向け。ストリーム指向。Cコンパイラが中間コードとしており人間が直接使うものではなかったが、その構文にはファンも存在した
Unix系システムでは、アセンブラを as と呼ぶのが一般的だが、実体はそれぞれのOSで異なる。GNUアセンブラを使っているものが多い。
同じ系統のプロセッサであっても、複数のアセンブリ言語の方言が存在する。アセンブラによっては他の方言のアセンブリ言語も使用可能な場合がある。例えば、TASMはMASM用コードを入力として受け付け可能だが、逆は不可能である。FASM（英語版）とNASMは文法がほぼ同じだが、サポートしているマクロが異なるため、相互の翻訳は困難である。いずれも基本機能は同じだが、追加機能に差異がある。
歴史

アセンブリ言語は、ごく単純なものまで含めれば、プログラム内蔵方式のコンピュータの最初期の1940年代から存在している。世界で最初に実用的に稼働したノイマン型電子計算機とされるEDSAC (1949) の initial orders（現代の用語ではブートローダーに相当するもの）は、テープにパンチされた十進によるアドレスを、内部表現の二進に変換するなどの機能を持っていた（命令については、「1文字のニーモニック」に見えるかもしれないが、それは実際には同機の機械語そのものである）。ナサニエル・ロチェスターは1954年に IBM 701 用アセンブラを書いている。1955年、Stan Poley が IBM 650 用言語アセンブリSOAP (Symbolic Optimal Assembly Program) を開発した。
コンピュータの歴史の初期には、このような、プログラムによって機械語プログラムを生成することを自動プログラミングと呼んだ。
ドナルド・ギリースは、まだ発明されていなかったアセンブラを開発中に、フォン・ノイマンから開発を即座に止めるように言われた、という1950年代初期ならではの逸話がある。当時は、人間が手作業でもできるような瑣末な仕事をコンピュータにさせるような時代が来るとは考えられておらず、単に時間の無駄だとノイマンは考えたのである。
歴史的には多数のプログラム（OSやアプリケーション）がアセンブリ言語だけで書かれてきた。ALGOLの方言であるESPOLで書かれた Burroughs MCP (1961) が登場するまで、オペレーティングシステムはアセンブリ言語で書くのが普通だった。IBMのメインフレーム用ソフトウェアの多くはアセンブリ言語で書かれていた。COBOL、FORTRAN、PL/I などが取って代わっていったが、1990年代になってもアセンブリ言語のコードベースを保守し続けていた大企業も少なくない。
初期のマイクロコンピュータでも同様に広く用いられた。これは、リソースの制約が厳しく、メモリやディスプレイのアーキテクチャが特殊だったからである。また、マイクロコンピュータ向けの高水準言語のコンパイラがなかったという面も重要である。また、初期のマイクロコンピュータのユーザは趣味としての使用が主であり、何でも自前で作るという精神もそれに影響していたと見られる。
1980年代から1990年代にかけて、ホームコンピュータ（ZX Spectrum、コモドール64、Amiga、Atari ST など）でもアセンブリ言語がよく使われていた。というのもそれらのBASICは性能が低く、ハードウェアの全機能を利用できないことが多かったためである。例えば、Amigaにはフリーウェアのアセンブリ言語統合開発環境 ASM-One assembler があり、Microsoft Visual Studio に匹敵する機能を備えていた。
Don French が開発した VIC-20 用アセンブラは 1,639 バイトという小ささで、世界一小さいアセンブラと言われている。アドレスをシンボルで表現でき、各種アドレス計算（四則演算、AND、OR、冪乗など）が可能だった。
1980年代のビジネスソフトでは、例えば表計算ソフト Lotus 1-2-3 などはアセンブリ言語で書かれていた。日本では松などが該当する。
1990年代に入っても、コンシューマーゲームの多くはアセンブリ言語でプログラムが書かれていた。しかしゲーム内容が複雑化し、プログラムの規模が増大するにつれて、アセンブラでは開発が困難となり、高水準言語による開発が主流となっていった。例えばプレイステーションではGCCが公式のSDKに含まれていて、標準の開発言語はC言語であった。この時代のゲーム機は3次元コンピュータグラフィックスの積極的な導入が始まっており、ハードウェア性能も向上したことから、C言語による開発も十分可能となったが、コンパイラの最適化能力が未成熟だったこともあいまって、ハードウェア性能を最大限引き出すにはアセンブリ言語を駆使した手動最適化や細かなチューニングが必要となることも多かった。セガサターンの最高性能を引き出してプレイステーションに対抗するには、アセンブリ言語を使うしかなかったと述べていた業界関係者もいた。ただし一方で、ファミコン時代すでにメタルスレイダーグローリーやスーパーファミコンのMOTHER 2・シムシティ、プレイステーションのクラッシュ・バンディクーで、開発の一部にLISPが使われていたという話もあり、当時のコンシューマーゲームの分野ではアセンブリ言語やC言語が全てだったというわけではない。
2000年代初頭、マイクロソフトは原始的なプログラマブルシェーダーに対応したDirectX (Direct3D) 8.0をリリースした。このDirect3D 8.0におけるシェーダープログラムは、グラフィックスハードウェアに依存しない中間言語（バイトコード）を出力することのできるアセンブリ言語（シェーダーアセンブラ）を使用して記述するものだった。2001年には世界で初めてプログラマブルシェーダーに対応したコンシューマーゲーム機として初代Xboxが登場したが、このXboxに搭載されていたグラフィックスAPIもDirect3D 8.x相当のカスタマイズ版であり、CPU上で実行するホストプログラム（ゲームアプリケーション本体のコード）はC++を使って記述する一方、GPU上で実行するシェーダープログラムの記述にはアセンブラを使用していた。のちにHLSLやCg (C for Graphics) といった高水準シェーディング言語が開発され、HLSLに対応したDirect3D 9.0以降はシェーダープログラムも高水準言語を利用して記述するようになった。Direct3D 10のシェーダーモデル4.0以降は、シェーダーアセンブラではなくHLSLの使用が必須となっている。
現在の最適化コンパイラは人手で書かれたアセンブリ言語のコードと同等の性能を発揮すると言われている（例外もある）。最近[いつ?]のプロセッサやメモリサブシステムは複雑化してきたため、コンパイラでもアセンブリ言語でも効果的な最適化がますます困難になってきている。さらにプロセッサが高性能化し律速が入出力やページングへ移ることで、コーディングが性能向上に貢献するケースは以前より少なくなっている。
一方C++やC#のような、Cよりもさらに高水準の言語が主流になってからも、コンパイラが出力したアセンブリコードを解析して最適化やチューニングの余地を探るといった手法は一般的に行なわれている。
利用

低水準言語であるアセンブラはC言語などの高級言語と異なる領域で利用される。
利用 > 目的

アセンブラを用いる目的として以下が挙げられる。
高速: レジスタ利用やループ展開の最適化
省フットプリント: ランタイムや標準ライブラリの排除
リアルタイム（時間的正確性）: GCスパイク、ページフォルト、プリエンプションの排除
ハードウェア操作
高級言語非対応命令の利用
挙動理解
利用 > 事例

アセンブリ言語が用いられる事例として以下が挙げられる。
組み込みシステム: 省フットプリントでのハードウェア操作が目的
電話機のファームウェア
自動車の燃料・点火システム
センサー
デバイスドライバや割り込みハンドラ、ブートコード、BIOS、POST
ハードウェアないしはファームウェアの呼び出し規約をアセンブリ言語によりカーネルやドライバにて使用している高級言語の規約へ変換することにより、主要な機能を高級言語で実装することができる。
暗号化: 高級言語非対応命令の使用が目的
ビット単位ローテート命令
数値計算: 高速化が目的
コンピュータゲーム
ライブラリ: 例 - BLAS, 離散コサイン変換（x264のSIMDアセンブリ版）
リアルタイムシステム: リアルタイム性が目的
フライ・バイ・ワイヤシステム: 航空航法システムの一種。テレメトリを厳密な制限時間内に解釈して対応する必要
医療装置
暗号アルゴリズムは常に厳密に同じ時間で実行することで、タイミング攻撃を防ぐ。
高度なセキュリティが要求され、環境を完全に制御する必要がある場合。
監視・トレース・デバッグのための命令セットシミュレータで、追加のオーバーヘッドを最小に保ちたい場合。
リバースエンジニアリング: 挙動理解が目的
デバッグ: 例 - コンパイラ最適化の確認
ソフトウェア改造: 例 - 商用コンピュータゲームの改造
ハッキング: 例 - コピープロテクト解除
学習: コンピュータの理解
自己書き換えコード
コードサイズの上限に制限がある環境
ブートセクタに格納するブートローダ。例として、MBRでは最大446バイト。
トラップ処理やシグナルハンドラ起動などのために、カーネルがプロセスのアドレス空間へ見せるコード。vDSOを用い、プロセスからはシェアードオブジェクトを読み込んだように見せる実装が多い。
見せるコードの範囲を正確に把握する必要があるため、コードのエントリだけでなく終了部にもラベルを与える。アセンブリ言語では容易だが、高級言語では一般に不要な機能なのでサポートされていない。
元来はユーザモード用のスタック上にカーネルからコードをコピーして実行していた。欠点として、スタックはユーザモードでの書き込みが禁止できず、スタック上でのコード実行がセキュリティホールとしてしばしば利用されたことから、実装方法の変更が進められている。
オブジェクトファイルに依存した機能
コンパイラが通常は使用しないセクション等にシンボルを定義することができる。例として、Linuxカーネルではモジュールへ公開するシンボルをマクロEXPORT_SYMBOL（ないしはその派生）へ与える。このマクロは、インラインアセンブリを用いてオブジェクトファイルのセクション.export_symbolへシンボルの情報を追加し、モジュールローダがシンボル解決にて使用できるようにする。マクロの内容はCPUアーキテクチャには依存せず、その定義もCPUアーキテクチャに依存しないヘッダファイル（include/linux/export.h）にあるが、C言語を含め高級言語のみでの実装が難しく、アセンブリが適している。
なお一方で、最近[いつ?]のコンピュータの命令セットはその多くはどれも似ている。したがって、どれか1つのアセンブリ言語を学ぶだけで、基本概念、どんなときにアセンブリ言語を使用するのが適しているか、高水準言語から効率的な実行コードを生成する方法をある程度は学習できる。
利用 > 高水準言語との連携

高水準言語の処理系の呼出規約（言語処理系ではなくOSやハードウェアベンダ側で共通化している場合もある）に従うことで、高水準言語と相互にコードを呼び出すことができる。後述のインラインアセンブラなどにより同一のモジュールに埋め込むこともできれば、別モジュールとしてリンケージエディタでリンクすることもある。
多くのコンパイラは、機械語を直接生成するのではなく、アセンブリ言語のコードを生成し、それをアセンブラに通している。人間によるデバッグや最適化などに便利である（機械による最適化には、内部表現を使ったほうが便利なので、あまり意味がない）。その意味ではアセンブリ言語は、目に見えない形ではあるが最も利用頻度の高いプログラミング言語といえるという主張もあるが、その意味では機械語が絶対的に最も利用頻度の高いプログラミング言語である。
インラインアセンブラのある言語ないし処理系では、ソース中にアセンブリ言語による記述を含めることができる。例えばLinuxカーネルではその利用が多い。アセンブリ言語と同様の利点が得られるかわりに、やはりアセンブリ言語と同様にプログラミング言語を使う利点（移植性など）が失われる。
1981年シーズンのアトランタ・ファルコンズ

| アトランタ・ファルコンズ 1981 |
| --- | --- |
成績:  7勝9敗
地区:  NFC西地区2位
CON:  NFC9位
結果:  レギュラーシーズン敗退
組織
オーナー:  ランキン・M・スミス・シニア（英語版）
GM:  エディ・レバロン（英語版）
HC:  リーマン・ベネット（英語版）
ホーム:  フルトン郡スタジアム
« 19801982 » 
1981年シーズンは、アトランタ・ファルコンズのNFL16年目のシーズン。リーマン・ベネット・ヘッドコーチの5年目のシーズン。
直近のチーム成績

| 年 | 成績 | NFC | 地区 | 勝 | 敗 | 分 | 率 | Div | Con | 平均得点 | 平均失点 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1981 | レギュラー敗退 | 9位 | 2位 | 7 | 9 | 0 | .438 | 3-3 | 6-6 | 26.6 | 22.2 |

| 1980 | ディビジョナル敗退 | 1位 | 1優勝 | 12 | 4 | 0 | .750 | 5-1 | 10-2 | 25.3 | 17.0 |
| 1979 | レギュラー敗退 | 10位 | 3位 | 6 | 10 | 0 | .375 | 2-4 | 5-7 | 18.8 | 24.3 |
| 1978 | ディビジョナル敗退 | 4位 | 2位 | 9 | 7 | 0 | .563 | 5-1 | 8-4 | 15.0 | 18.1 |
| 1977 | レギュラー敗退 | 6位 | 2位 | 7 | 7 | 0 | .500 | 3-3 | 7-5 | 12.8 | 9.2 |
| 1976 | レギュラー敗退 | 11位 | 3位 | 4 | 10 | 0 | .286 | 2-5 | 4-8 | 12.3 | 22.3 |
| 1975 | レギュラー敗退 | 12位 | 3位 | 4 | 10 | 0 | .286 | 3-3 | 3-8 | 17.1 | 20.6 |
| 1974 | レギュラー敗退 | 12位 | 4位 | 3 | 11 | 0 | .214 | 0-6 | 3-8 | 7.9 | 19.4 |
| 1973 | レギュラー敗退 | 5位 | 2位 | 9 | 5 | 0 | .643 | 4-2 | 7-4 | 22.7 | 16.0 |
| 1972 | レギュラー敗退 | 8位 | 2位 | 7 | 7 | 0 | .500 | 3-3 | 5-5 | 19.2 | 19.6 |
| 1971 | レギュラー敗退 | 7位 | 3位 | 7 | 6 | 1 | .536 | 3-2-1 | 4-6-1 | 19.6 | 19.8 |
プレシーズン

| 週 | 日 | 相手 | 結果 | 戦績 | 開催地 | 備考 |
| --- | --- | --- | --- | --- | --- | --- |
 勝利   敗戦  at：敵地での対戦
レギュラーシーズン

| 前年 | AFC> 西地区 | AFC> 中地区 | AFC> 東地区 | NFC> 西地区 | NFC> 中地区 | NFC> 東地区 |
| --- | --- | --- | --- | --- | --- | --- |
| 1位 | チャージャーズ | ブラウンズ | ビルズ | ファルコンズ | バイキングス | イーグルス |
| 2位 | レイダース | オイラーズ | ペイトリオッツ | ラムズ | ライオンズ | カウボーイズ |
| 3位 | チーフス | スティーラーズ | ドルフィンズ | 49ers | ベアーズ | レッドスキンズ |
| 4位 | ブロンコス | ベンガルズ | コルツ | セインツ | バッカニアーズ | カージナルス |
| 5位 | シーホークス |  | ジェッツ |  | パッカーズ | ジャイアンツ |
：1度対戦　 ：2度対戦
| 週 | 日 | 相手 | 結果 | 戦績 | 開催地 | 備考 |
| --- | --- | --- | --- | --- | --- | --- |
 勝利   敗戦  at：敵地での対戦
レギュラーシーズン > 順位表

| NFC西地区 1981> チーム | NFC西地区 1981> 勝 | NFC西地区 1981> 敗 | NFC西地区 1981> 分 | NFC西地区 1981> 勝率 | NFC西地区 1981> Div | NFC西地区 1981> Con | NFC西地区 1981> 総得点 | NFC西地区 1981> 総失点 | NFC西地区 1981> 平均得点 | NFC西地区 1981> 平均失点 | NFC西地区 1981> SOS | NFC西地区 1981> SOV | NFC西地区 1981>  | NFC西地区 1981>  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| (1)サンフランシスコ・49ers | 13 | 3 | 0 | .813 | 5-1 | 10-2 | 357 | 250 | 22.3 | 15.6 |  |  |  |  |
| アトランタ・ファルコンズ | 7 | 9 | 0 | .438 | 3-3 | 6-6 | 426 | 355 | 26.6 | 22.2 |  |  |  |  |
| ロサンゼルス・ラムズ | 6 | 10 | 0 | .375 | 2-4 | 5-7 | 303 | 351 | 18.9 | 21.9 |  |  |  |  |
| ニューオーリンズ・セインツ | 4 | 12 | 0 | .250 | 2-4 | 2-10 | 207 | 378 | 12.9 | 23.6 |  |  |  |  |

| NFC 1981> 順 位.地区優勝 | NFC 1981> チーム.地区優勝 | NFC 1981> 地 区.地区優勝 | NFC 1981> 勝.地区優勝 | NFC 1981> 敗.地区優勝 | NFC 1981> 分.地区優勝 | NFC 1981> 勝率.地区優勝 | NFC 1981> DIV.地区優勝 | NFC 1981> CON.地区優勝 | NFC 1981> SOS.地区優勝 | NFC 1981> SOV.地区優勝 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | サンフランシスコ・49ers | 西 | 13 | 3 | 0 | .813 | 5-1 | 10-2 |  |  |
| 2 | ダラス・カウボーイズ | 東 | 12 | 4 | 0 | .750 | 6-2 | 8-4 |  |  |
| 3 | タンパベイ・バッカニアーズ | 中 | 9 | 7 | 0 | .563 | 6-2 | 9-3 |  |  |
ワイルドカード
| 4 | フィラデルフィア・イーグルス | 東 | 10 | 6 | 0 | .625 | 4-4 | 7-5 |  |  |
| 5 | ニューヨーク・ジャイアンツ | 東 | 9 | 7 | 0 | .563 | 5-3 | 8-6 |  |  |

| 6 | ワシントン・レッドスキンズ | 東 | 8 | 8 | 0 | .500 | 3-5 | 6-6 |  |  |
| 7 | デトロイト・ライオンズ | 中 | 8 | 8 | 0 | .500 | 4-4 | 6-6 |  |  |
| 8 | グリーンベイ・パッカーズ | 中 | 8 | 8 | 0 | .500 | 4-4 | 7-7 |  |  |
| 9 | アトランタ・ファルコンズ | 西 | 7 | 9 | 0 | .438 | 3-3 | 6-6 |  |  |
| 10 | セントルイス・カージナルス | 東 | 7 | 9 | 0 | .438 | 2-6 | 4-8 |  |  |
| 11 | ミネソタ・バイキングス | 中 | 7 | 9 | 0 | .438 | 4-4 | 6-6 |  |  |
| 12 | ロサンゼルス・ラムズ | 西 | 6 | 10 | 0 | .375 | 2-4 | 5-7 |  |  |
| 13 | シカゴ・ベアーズ | 中 | 6 | 10 | 0 | .375 | 2-6 | 2-10 |  |  |
| 14 | ニューオーリンズ・セインツ | 西 | 4 | 12 | 0 | .250 | 2-4 | 2-10 |  |  |
タイブレーク
地中海盆地

生物地理学における地中海盆地 (ちちゅうかいぼんち, Mediterranean Basin) または地中海地域 (ちちゅうかいちいき, Mediterranean region) は、穏やかで雨の多い冬と暑く乾燥した夏の地中海性気候である地中海周辺の地域を指し、特有の地中海性森林がある。経験則として、地中海盆地はオリーヴが育つ旧世界地域である。しかし、オリーヴは地中海性気候を持つ世界の他の地域でも生長し、地中海周辺の多くの地域では、地中海性気候を持たず、オリーヴは育たない。
地中海盆地とオリーヴの生息域
地中海盆地にある国家の地図
地理

地中海盆地は、ヨーロッパ、アジア、アフリカの3つの地域に及んでいる。
ヨーロッパは北側に位置し、イベリア半島、イタリア半島及びバルカン半島の3つの大きな南ヨーロッパの半島が地中海性気候へ入っている。スペインとフランスを分けるピレネー山脈、中央ヨーロッパからイタリアを分けるアルプス山脈、アドリア海の東側に沿ったディナル・アルプス山脈、西ヨーロッパや中央ヨーロッパの温帯から地中海性気候を分けるバルカン半島のバルカン山脈、ロドピ山脈などの山脈が取り巻いている。
地中海盆地は西アジアへも及び、中央部の温帯の山脈を除き、トルコの半島の西部や南部を占めている。盆地には、地中海の東端にある地中海性気候のレバントが含まれ、シリア砂漠やネゲヴ砂漠が東端、南端になっている。
北アフリカを横切るアトラス山脈によってサハラ砂漠から分けられる地中海性気候が北西アフリカのマグリブ北部に存在する。地中海東部では、サハラ砂漠は、リビアのキレナイカ半島北部を除いて、乾燥した地中海性気候となっている。
ケッペンの気候区分による地中海周辺地域の気候地図
地形と気候

地中海盆地は、古代に安定したユーラシア大陸に、北方へ動いていたアフリカプレートとアラビアプレートが衝突したことで形成された。北へ動いていたアフリカ・アラビアによって、古いテチス海はなくなり、アフリカもその一部であった古代の巨大なゴンドワナ大陸からユーラシア大陸を分けた。ほぼ同時（1億7000年前、ジュラ紀）に、テチス海の少し前に形成された小さなネオテチス海は東端を閉じられた。この衝突はスペインのピレネー山脈からイランのザグロス山脈まで及び、広大な山脈を押し上げた。アルプス造山運動として知られるこの造山運動は、ほとんどが漸新世（3400〜2300万年前）や中新世（2300万年前〜530万年前）に起こった。ネオテチスはこれらの衝突の間にさらに大きくなり、隆起やプレートの沈み込みにつながった。中新世後期の約600万年前、地中海はアラビアの圧力により西端が閉じられ、海を消滅させた。大西洋が少なくとも69回盆地を氾濫させたときの水位低下と氾濫は、メッシニアン塩分危機で最もよく知られている。
さらに中新世の終わりは、地中海盆地の気候を変動させた。化石証拠からの判断では、中新世の間の地中海盆地は、夏に雨が多く、比較的湿度が高い亜熱帯気候だったことを示しており、このことで照葉樹林が成立していた。最後の320万〜280年、鮮新世時代に、夏の降雨が減少し、地中海性気候への移行が生じた。このような変化によって亜熱帯の照葉樹林は衰退し、これらはイベリア半島や北アフリカの大西洋岸沖にあるマカロネシアにしがみつくように残存するに過ぎなくなり、現在の地中海の植物が発展し、乾燥した夏に水分を失うのを防ぐ小さくすべすべした、針葉樹林や硬葉樹林、灌木が優占するようになった。これらの森林と灌木の多くは、人間が居住した何千年かの間に見分けが付かないほどに変わった。現在では、以前大きな森林地帯だった自然地域であまり変化していないところはほとんど存在しない。
歴史

→詳細は「地中海世界」を参照
ネアンデルタール人は、西アジアや約230,000年前に始まったヨーロッパの氷河ではない場所に居住した。人間は100,000年ほど前にアフリカから西アジアへと移動した。クロマニョン人として知られる人間は、およそ50,000〜40,000年前にヨーロッパへと移った。
最後の氷河時代（ウィスコンシン氷結）は、およそ21,000年前に最終氷期最盛期に達し、約12,000年前に終了した。完新世の気候最温暖期として知られる温暖な時代は、氷河時代に続いた。
羊やヤギに加えて、小麦、ヒヨコマメ、オリーヴを含む食用作物は、紀元前9千年紀に地中海東部で取り入れられ、農業集落がつくられた。近東の作物は、紀元前7千年紀にヨーロッパ南東部に広がった。ポピーやエンバクは、紀元前6千世紀から紀元前3千世紀にかけてヨーロッパで取り入れられた。農業集落は地中海盆地まで広がった。紀元前4500年から1500年にかけて、ヨーロッパで巨石記念物が構築された。
夏期の季節風の強まりは、9000〜7000年前に、湖、川、湿地と、草原であったサハラを横断する降雨を増加させた。気候が不安定となった時代の後、サハラは紀元前4千年紀に砂漠地帯となった。
農業

小麦は、地中海盆地周辺で育てられる最も優勢な穀物である。また、豆類や野菜も育てられている。特有の作物としては、オリーヴがある。イチジクは、別の重要な果樹または柑橘類（特にレモン）や灌漑がある場所で育てられる。ブドウは、重要なつる植物で、フルーツやワインを作るために育てられる。米や夏野菜は灌漑地域で育てられる。
小早川怜子

小早川 怜子（こばやかわ れいこ、1982年11月17日-)は、日本のAV女優。リーズプロモーションに所属していたが、現在はカプセルエージェンシーに所属。趣味は料理と写真。
略歴・人物

2012年にAVデビューした、巨乳の熟女系AV女優。
2022年9月24日に神田明神ホールで行われたAsia Pacific Collectionではセックスワーカーを代表するひとりとしてランウェイを歩く。
2010年以前は杏華という名義でキャンギャル活動をしていた。
出演作品 > アダルトVR

2018年
ツン顔でイキガマンするオンナ教師（10月23日、ワープエンタテインメント）
2019年
Wれいこ共演VR!! 二人は女上司 黒パンスト美脚で僕の股間を足コキ尻コキでトコトン教育指導する美熟女上司VR 澤村レイコ / 小早川怜子（4月26日、マドンナ）
2020年
美尻コンテストの控室でデカ尻お姉さん達に狙われたスタッフのアナタ!! 本番に向けてのパンプアップで杭打ち騎乗位、顔騎、ハーレム尻コキで夢の痴女られタイム突入～!! 蓮実クレア / 篠田ゆう / 小早川怜子 / 神ユキ（6月10日、MOODYZ）
人間椅子VR (Human Chair VR) 顔面騎乗&チ○ポ騎乗で息が詰まるほど痴女られまくり! あお向けアングルW巨尻SPECIAL!! 蓮実クレア / 小早川怜子（6月24日、ワンズファクトリー）
ママさんジョギングサークルのコーチをしてる僕 トレーニング終わりに皆で飲んでると欲求不満の本性を現したほろ酔い奥様方が僕のチ○ポを奪い合う4Pハプニング!! 川上ゆう / 小早川怜子 / 加山なつこ（8月7日、マドンナ）
再婚相手を周りは資産目当ての後妻というが本当は俺の絶倫チ○コに惚れて【爆乳】を揺らし【デカ尻】を振るドスケベ女!（8月31日、SODクリエイト）
【M男専用】「ここでシコリなさい…」小早川怜子に野外露出させられるVR 遠隔オナニーJOI・全裸散歩で排尿指示・拘束アナル調教… ご主人様の命令には絶対服従!（12月3日、SODクリエイト）
2022年
VR麗しの熟女湯屋 いらっしゃいませ即尺 & 和室ねっとり恋人プレイ 小早川怜子（9月22日、グローバルメディアエンタテインメント）
VR麗しの熟女湯屋 湯船で潜望鏡フェラ & ぬるぬるマット奉仕プレイ 小早川怜子（10月14日、グローバルメディアエンタテインメント）
2025年
【VR】【8K】【VR集団レ×プ】一家まるごとの女どもを、これから襲います。（1月30日、SODクリエイト）
出演作品 > イメージDVD

Fabulous（2021年3月5日、ファインピクチャーズ）※Blu-ray版同時発売
ヴィーナス・テルメ（2021年9月29日、オルスタックソフト販売）※Blu-ray版同時発売
女流あん摩師 怜子（2022年1月28日、オルスタックソフト販売）※Blu-ray版同時発売
月刊 隆行通信 Vol.31（2007年11月1日、スタジオ デュオ）
女神の素顔（2008年2月1日、心交社）
女神の素顔 2（2008年5月30日、心交社）
隆行通信 THE SPECIAL VERSION VOL.5（2010年4月28日、スタジオ デュオ）他出演:麗華、りおん、中村彩加、月見栞
書籍 > 写真集

小早川怜子（2019年8月22日、徳間書店、撮影：佐藤裕之）ISBN 978-4-19-864916-6
書籍 > ポーズ集

パーフェクトヌードポーズ model 小早川怜子（2020年3月31日、ジーオーティー、撮影：田村浩章）ISBN 978-4-8236-0032-6
書籍 > デジタル写真集

Fabulous デジタル写真集 小早川怜子（2021年3月17日、ファインピクチャーズ、撮影：SHOOTING STAR）
Fitch LOOK BOOK（2021年9月30日、FANZA BEAUTY COLLECTION）- 多人数モデル出演のデジタル写真集。
Venus【グラビア写真集】小早川怜子（2021年11月5日、プレステージ出版、撮影：松田忠雄）
Venus【ヌード写真集】小早川怜子（2021年11月5日、プレステージ出版、撮影：松田忠雄）
書籍 > インタビュー集

ハタチになったら死のうと思ってた AV女優19人の告白（2018年7月27日、ミリオン出版、著者：中村淳彦）- 実話ナックルズ連載『職業、セックス。〜わたしが裸を売る理由〜』をまとめたインタビュー集。小早川のインタビューを収録。 ISBN 978-4-8130-2278-7
出演 > オリジナルビデオ

世にもエロスな物語（2018年、ファーストインプレッション）「乱れる背徳の旋律」怜子役
出演 > インターネット放送

トイズハートプレゼンツ「とりあえずナマで！」（2019年8月3日、Youtube・トイズハートチャンネル）＊第16回ゲスト
出演 > テレビ

どぶろっくと山岸逢花の ＃やらかしジャッジメント（2022年1月5日‐27日、刺激ストロングチャンネル）
Roxio Creator

| --- | --- |
開発元:  コーレル

最新版:  Roxio Creator NXT9    / 2021年
対応OS:  Windows
種別:  ライティングソフト
ライセンス:  シェアウェア
公式サイト:  http://www.roxio.jp/
テンプレートを表示
Roxio Creator（ロキシオ クリエーター）は、米ソニック・ソルーションズが開発、コーレルが販売しているライティングソフトウェア。Mac版のライティングソフトとしては同開発のRoxio Toastが存在する。
概要

Roxio Creatorは、ライティングソフトウェアだけでなく、簡易動画編集などができたり、DVDの再生ができたりと、複数のソフトウェアが一つにパッケージングされている。詳細は以下を参照。
→詳細は「Roxio Creatorの搭載ソフト」を参照