Skip to content

meeting minutes

Jump to bottom
NAGAMINE Hideaki edited this page Jan 19, 2017 · 16 revisions

2017/01/13 ミーティング

参加者: 佐藤, 李, 小山, 長嶺

  • アプリケーション評価用のC++テストコードの共有

    • compatibility: C的なコード
    • class: クラス宣言, virtual, friendなど
    • derive: 継承
    • member: クラスメンバー

  • 対応状況

  • 次回: 2017/01/20 16:00

2017/01/06 ミーティング

  • 3月までにやること
    • クラスおよびpragmaの C++ -> XcodeML 変換を扱う処理の実装
    • テンプレートの C++ -> XcodeML 変換に関する設計
    • 線表の作成
    • テスト用C++コード(後述)の共有
  • アプリケーションの評価方法
    • (主に)テスト用C++コードをXcodeMLに変換・C++に逆変換したものをコンパイルし動作確認
    • 必要に応じて変換・逆変換後のソースコードをチェック

2016/08/31 ミーティング

参加者: 佐藤, 村井, 李, 小山, 長嶺

  • C++のstructで宣言されたクラスは、XcodeMLでは<structType>ではなく<class>として取り扱う。
  • リファレンスをreferenceTypeなどの特別な要素で表現する。assignExprなどの中では普通の変数として処理する。(参照)
  • OpenMPのpragmaは現在テンプレート定義の中で使用することができる。XMPでも同様のことを行いたい。
  • テンプレートをXcodeMLで表現する方法とC++ソースコードに復元する方法 (参照)
    • テンプレートの定義を<globalDeclarations>要素内に入れる。
      • テンプレート定義はXcodeML文書をC++ソースコードに戻すとき(逆変換)にだけ必要になる。そのため、逆変換にとって都合の良い位置(=globalDeclarations)にあったほうが良い。
    • インスタンス化された(元のプログラムで使用された)テンプレートは暗黙のうちに完全特殊化が定義されたものとみなし、これを<functionDefinition>要素などで表現する。
    • 新たに付け加えられた特殊化の定義をC++ソースコードに復元するときには__attribute__ ((weak))属性を付ける。完全特殊化の定義はリンク時に唯一でなければならないため。
    • クラステンプレートをインスタンス化したときに行うこと
      • <typeTable>に新しい要素を付けくわえる。
      • メソッドの定義は関数テンプレートと同様に<functionDefinition>要素で表現する。
  • クラス、テンプレートなどの機能について今期中に完成しそうなこと、当初の目標との差異をリストアップする。

2016/08/25 ミーティング

参加者: 李, 和田, 小山, 長嶺

  • <ifStatement>, <whileStatement>, <forStatement>の子要素の取り扱い。<body>子要素はたとえ単文であっても<compoundStatement>で囲う(正規化)。<ifStatement>の<else>子要素は省略可能。仕様に明記する。
  • typeTable内に同じ型を表すデータ型識別名が複数ある場合は確かにあるが、現状うまくいっているので問題になる可能性は低いだろう。正変換・逆変換の実装で同一性を計算できるので仕様で定めなくてもよい。
  • structのタグ名の表示される位置が仕様で定義されていない。C++で問題になる。
  • *.cと*.cppでstructの扱いを変える。Cでは<structType>要素として、C++では<classType>要素として表現する。現在のC++ではstructとclassは区別されない(実体として同じものを宣言する)のでこの方針でうまくいくのではないか。もしも必要ならis_struct属性で区別できる。
  • クラス内クラスのアクセス指定をどう表現するか(下図)。<classType>の要素に属性をつける? クラス内に登場するプレースホルダーに属性をつける?
    • そもそもXMPは意味解析をしないので非合法なメンバーアクセスを弾いたりしない。この情報が必要になるのはソースコード復元時。
class A {
 class B {} ;
 public:
 class C {} ;
};

  • リファレンス型を表現する方法がない。クラスより優先度は低いもののできるだけ早く導入したい。

  • テンプレートの仕様を9月末までに検討して文書化する。

    • インスタンス化されるたびに特殊化するのはどうか?

  • C/C++コメントをXcodeMLで表現する要望。今期できる?

  • 次回(仮): 2016/8/31 13:00

2016/07/26 ミーティング

参加者: 佐藤, 村井, 木村, 小山

  • 先週に引き続いて typeTable がらみの修正中。 ややこしい問題は placeholder で解決できるんじゃないか？（placeholder がなくて、かつややこしい場合は、扱わないことにしていいのでは？） ⇒ 従来の C 言語限定との互換性を意識しておきたい

  • 次回: 2016/8/1 14:30

2016/07/20 ミーティング

参加者: 佐藤, 村井, 李, 木村, 小山

  • 逆変換で typeTable の依存関係を解析する件、 placeholder を使うのではなかったか？ ⇒ placeholder が無い場合に対応する必要がある。

  • 逆変換で const int を typedef 経由にするのは OK.

  • mangle されてその名前がリンカまで到達することはないか？ ⇒変数宣言だけなら無い。関数の引数になるとあるかも？ ⇒いや、そもそも typedef は同じ型扱いになるのだから、元の型名で出るはず。

  • google docs の ID の件。ミーティング中にアドレスをいただいたので設定済み。

  • 次回 2016/7/26 14:30

2016/07/12 ミーティング

参加者: 村井, 李, 木村, 小山

  • google docs のチェックシート https://docs.google.com/spreadsheets/d/1kb-X9b-w5b4kvUL59yb7H5PS-NY-RmEpfZBx5ukvOEw について、編集権限を設定するため、 Google の ID (gmail のアドレス) をお伝えいただく。

  • そのチェックシートの B～D 欄 に各人が自由に書き込んで良い欄を作ったので、 もとの http://ezoeryou.github.io/cpp-book/C++11-Syntax-and-Feature.xhtml のページを読みながら、優先度づけなどを書き込んでいく。

  • よりややこしい話があるようなら issue 化する。

  • 優先度の判定基準としては、

    • XcodeML 仕様の全体に影響が大きい話は先に考えるべきである。
    • 簡単に実装できそうなことは特に優先度が高くなくてもやってしまおう。
    • 正変換・逆変換ツールを作ってみないとわからないことが多いので、 正変換・逆変換ツールを実際に作るという部分をはっきりさせるのが目的。
    • それ以外の部分については、難易度が高そう(あるいは不明)だが 独立性が高いと思われる機能 (例えば例外とかラムダ) は、優先度が低い。 (優先度が低い部分はまるごと今期の着手対象から外す)
    • template の扱いは悩ましい。 今期に着手できるような簡単な話ではないので優先度を低くせざるを得ないが 全体の影響は大きいのでまるまる無視しているわけにもいかない。

2016/07/04 ミーティング

参加者: 佐藤, 村井, 李, 木村, 小山, 長嶺,

  • 実装方針が明確なglobalDeclarationsよりも実装方針がまだ明確でないtypeTableの対応を優先する
  • GitHubのwiki(ここ)を使う
Clone this wiki locally