LLVMによるプログラミング言語の実装 – 日曜研究室
最近の投稿 問題: 積み木を10個積み上げるのにかかる時間は 2020/8/20 木曜日 Google の G Suit Team から “[Action Required] Remove internal links to the G Suite Domain Contact page for your organization” ていうメールが来た 2020/8/14 金曜日 NZXT H1 と ROG STRIX B550-I GAMING で組んでみた 2020/7/17 金曜日 花粉症対策2019 2019/3/16 土曜日 マルチディスプレイ時のDisplayPort問題を何とかしてみた 2019/1/12 土曜日 REALFORCEソフトウェアがインストールできない(解決済) 2018/12/6 木曜日 GeForce RTX 2080 Founders Edition を買
中間言語としてのJavaScriptはどうなったのか - .mjtの日記復帰計画
prev: http://d.hatena.ne.jp/mjt/20080904/p2 なぜか３年前の記事が急にブックマークされていたのでフォローする記事。 ↑の記事の1年後、InfoQの記事( http://www.infoq.com/news/2009/09/javascript-compilation-target )でいくつかのJavaScriptにコンパイルする言語が紹介された。もちろん、GoogleのGWT(Google Web Toolkit)もJavaScriptを出力するJava環境と言える。 先の記事で触れたエミュレータでの活用は、見たところDirect-threadingによるものに限られているように見える。つまり、CPU命令をJavaScript的なfunctionとして実装し、CPU命令と１対１対応させる。Google V8のような、Direct-threadin
ウェブためのユニバーサルなバイトコードは必要か
原文(投稿日：2013/05/22)へのリンク どのブラウザでも動くウェブのバイトコードは価値があるだろうか。LLVMはソリューションとして成り立つだろうか。ネイティブコードをブラウザ上で動かすにはMozillaのasm.jsとGoogleのPNaClのどちらがいいだろうか。この記事ではこれらについての意見を紹介する。 ArsTechnicaのJavascriptで書かれた動画コーデックについての記事に対するRanizのコメントは同記事のコメント欄やウェブ上でさまざまな反響を起こした。Ranizは“ブラウザ向けバイトコードを標準化し、開発者がさまざまな言語を選択できる”ようにして、開発者がJavaScriptを使わざるを得ない状況を脱し、好きなウェブプログラミング言語を選択できるようにすることを提案している。そのバイトコードはJVMやCLRのバイトコードと同じように、ウェブ開発の共通プラッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
