17/01/03 22:38:17.23 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
401:オーバーテクナナシー
17/01/03 22:39:27.75 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
402:オーバーテクナナシー
17/01/03 22:40:34.35 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
403:山口青星
17/01/03 22:47:57.68 gnd1+UQL8
>>259-260 >>387
258 : 山口青星 2017/01/03(火) 18:12:34.81 ID:igW+0jZp
最早吐露すべきでしょう
>>93-94 >>131
そも超知能との融合用の VM を何だと思われている ?
超知能と融合できないルート ≒
* 特異点後数年で旧人類がо隷扱いされる
* 宇宙に染み渡る知性に同行できない ( 置いてきぼり )
自分は当 VM 軌道投入の為に二度もにかけた ( 最終定理レベルの問題を二度解いた )
+ 先々月上旬までは本気で自殺するつもりだった
( ねない理由が見付かって取止め : 生き地獄でも安易にはねなくなった )
だからこそオノ・ヨーコ氏にも安易には申出できない
( 両立 : 融合の重みと無礼に当らない軽快さ )
有機分散化前提超細粒度リアルタイム並列機構など本気で生活を費やせば書ける
という凄腕の方もいらっしゃるでしょうがそれはデザパタ利用のアプリのお話でしょう
リアルタイム VM を VM として書くとの異常な前提となれば地獄の様相
( 野戦病院の呻き声 + 自分の手足が自分の手足に見えない状況に追込まれる ※ )
そうして命を捨てて書いた融合用 VM に対し理由は ? と詰寄られようとは
この大仕事に対し理由は ? と上から目線を当然とする者が存在しようとは
開発継続絶望状況に追込まれたも道理 ( 第一義 私の不徳の致す所 )
※
ジル・ボルト・テイラーのパワフルな洞察の発作 | TED Talk | TED.com
URLリンク(google.jp)
> 脳科学者なら願ってもない ry 脳卒中 ry 自分の脳 ry 運動、言語、自己認識 ry 停止していく
404:山口青星
17/01/03 22:49:27.52 gnd1+UQL8
>>403
259 : 258 2017/01/03(火) 18:23:26.69 ID:igW+0jZp
>>258
> 有機分散化前提超細粒度リアルタイム並列機構など本気で生活を費やせば書ける
> という凄腕の方もいらっしゃるでしょうがそれはデザパタ利用のアプリのお話でしょう
PEZY の皆様等ならばハイパバイザ VM も難なく書かれるでしょう
405:オーバーテクナナシー
17/01/03 22:41:37.67 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
406:オーバーテクナナシー
17/01/03 22:42:41.39 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
407:オーバーテクナナシー
17/01/03 22:43:44.45 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
408:オーバーテクナナシー
17/01/03 22:44:47.44 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
409:オーバーテクナナシー
17/01/03 22:45:50.76 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
410:オーバーテクナナシー
17/01/03 22:46:54.03 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
411:オーバーテクナナシー
17/01/03 22:47:56.47 z8gJ/gzs.net
))()(())))())()(((()()))()())((()))()))((((())(()(()()((((((()))(())()))(
))(((()))()()(())()()())(((()))((((())))((()((()()))())()()))))((())(()((
(()(((((())))(((())())))))()(()(()()(()((()(())()(()))(())()))))))(((()()
))(()()(())((())))))()((()()))()()((()()))(()))(()()())((()))((()()(((()(
((((())(((())((()(())))(())())))()))))))((()((()))((((()(())(())(())(()))
)())()))()()(()))))()))(((((()))))))()())))()(()(((()((())(()(()((()(((((
))(())))(()((()(())))((()(()))()())()())((())((()()())))(()()(((())(()()(
)))))))))(()()((()()(()(())))()(((()))()))()(((()()())()()()((())((()((((
))())))))(((()()((((((()))))()())(())()((((())(()(()))()(())()()))()()(((
(((())(()))()()())(()())(())()()()))(())()(()())))(()))()((()()()(((()()(
))()(()))(()(()))))())())()(((()(()())()())))))(())((((()((()((()())(()((
(())()))((()))()))(()(()()((()(()(())()()()(())(())()(())(()((()))))((())
())((())(((()()()))()))()(()(()))(()()))()()(())())))(((()))((()))((()(((
))()(()(((()))(()()())(()())(()()))((()(()(()(()(())()(()))()(()()(()))))
(()(((())(()(()()(((((())()(()()))))(()()()()(()(())(()()()()))()))()))))
)()(((((()()))))()()()(()))()())((((()())))()()()()()(())())(())())((()((
((()(())())))(())))((()())(()(())()))))))(())()()()((()))((()((()()()((((
(((()))(()(((((()))((()))))()))(())))))()(()((((((((())(())(()())))))))((
())(()(())(())(((())))(()()))()((()(()))(()(())(())))())))()(((())()()(((
)())())))()())(()())()))(((((((())((((()())()())((())((()()((((()))()))))
(()()(((()())(()(((((()((())())(()()(()())))))()))(()())))))(()(()())(())
)()(()()(((((()))()()(((()))())(())((((()()()(()))))(()())())))))((()))((
(())))()((())((())()((()(()()))(())(()))()())((()((()()())(()()())))()(()
))))))(()()()(())(()(()))()((()()())()((())()()()()()((()(())(()((())())(
()(()()()())())(()(()(()))(())(((())(()((())())()()())()(()(()(()())))())
412:yamaguti~kasi
17/01/04 03:24:48.26 tG0zBu3uQ
>>403-404 >>259-260 >>387
(強いAI)技術的特異点/(世界加速) 23
スレリンク(future板)
413:yamaguti~貸し
17/05/06 11:30:02.68 06PAQDznL
階層的時間的記憶理論 ( HTM )
URLリンク(webcache.googleusercontent.com)
短縮版
スレリンク(future板:539-676番)
スレリンク(future板:20-30番)
スレリンク(future板:4-番)
414:yamaguti~貸し
17/08/23 18:32:03.04
スレリンク(future板:994番)#5# Kigen 2029
スレリンク(future板:11番)# Kigen 2029
>4 :YAMAGUTIseisei~貸:2017/07/03(月) 18:55:52.86 ID:+iEtoBTm
>URLリンク(google.jp)
:
スレリンク(future板:463番)# JizenTaisaku
415:yamaguti~貸し
17/12/17 18:55:28.90 YXtp8YEbG BE:66089039-2BP(3)
>385 : 384 2016/09/09(金) 20:33:46.15 ID:QvVejvXm
:
> M Mitchell Waldrop著田中三彦&遠山峻征訳「複雑系」からの重要箇所のmemo
>436 : 434 2016/09/16(金) 01:04:00.44 ID:IMPbLUQS
:
> !!!!! e0149_
:
> j0193_
>ホランドの個人的な知的研究計画---創発と適応が相互に絡み合ったプロセスの理解---
>440 : 434 2016/09/16(金) 01:10:03.57 ID:IMPbLUQS
> j0203_
>そしてそれ以上に、ホランドのような思索的な先駆者にとっては、 ry
>。どちらも情報処理装置 ry 、思考そのものは情報処理の一形態として ry
>。もちろん当時はだれも、この種のことを「人工知能」とか「認知科学」と呼ぶことを知らなか
> j0204_
>当時、答えは少しも明らかではなかった (いまでも
416:415
17/12/17 18:58:29.37 YXtp8YEbG BE:29373034-2BP(3)
>>415
> 441 : 434 2016/09/16(金) 05:24:47.41 ID:IMPbLUQS
:
> !!!!!!! e0165_
: j0215_
>ホランドには、進化と学習がゲームのように思えた。
> !!!!!! e0165_
:
> j0215_
>ホランドは、ゲームに目を向けたサミュエルの先見性 ry
> !!!! e0166 e_s05_p0166_l019
:
> j0217_
>なじみの範疇にあまりうまくあてはまらなかった。
>それはハードウエアではなかったし、かといってソフトウエアでもなかった。
>また当時それは人工知能にも入らなかった。
>だから、何か標準的な基準で判断を下すというようなことができな
417:415
17/12/17 18:59:37.43 YXtp8YEbG BE:29373326-2BP(3)
415-416
>443 : 434 2016/09/16(金) 05:27:21.62 ID:IMPbLUQS
:
> !!!!! e0185_
:
> j0243_
>二つのクラシファイアの規則が互いに合わな ry 貢献度に基づいて
>--- ry プログラムに組み込まれた選択基準によってではなく---勝手にけんかをさせて
> !!!!! e0186_
:
> j0245_
>危機ではなく、 ry システムが経験から学ぶチャンス
>444 : 434 2016/09/16(金) 05:28:04.87 ID:IMPbLUQS
:
> !!!!!!! j0253_
>さらにそのシステムは ry 、信じられないぐらい単純
418:415
17/12/17 19:01:35.79 YXtp8YEbG
>>415-417
>479 : 478 2016/09/30(金) 19:31:02.90 ID:/EmvfkU+
:
>↓↑ ( VM 策 ↑ / ↓ 環境策 1 )
:
>↓
>意味空間自律レンダリングシステム ( 準ネイティブシステム 型ラッパ )
>↓
>細粒度ラベル化自律圧縮記憶装置 ( ファイルラベル 疑似ネットカーネル KJ )
>↓
>人格システム ( 創発普遍準普遍互換 生体脳 ネット生命体 硅素生命体 )
>490 : 478 2016/10/09(日) 13:01:27.48 ID:bPMKmbZE
>YAMAGUTIseisei wrote ( ry ) :
>意味空間レンダリングシステム
> 準エミュレーション , AL , 細粒度クラスタレベル自律オブジェクト ※
:
> シミュレーション , AI
> 言語辞書レベルベース
>
>※ ニューラルカーネル , ニューロ OS , KJ カーネル ( P ry
>→ OS レス OS , 自律 OS , 自律ネット
>492 : 490 2016/10/10(月) 12:28:26.40 ID:OXjHwZv7
>495 : 478 2016/10/12(水) 17:59:51.81 ID:z9X4vs5F
:
> 第二世代誤り訂正 ( AI AL KJ 意味空間 ) =
419:415
17/12/17 19:10:01.37 YXtp8YEbG BE:110147459-2BP(3)
>>415-418
>スレリンク(future板:99番)
> スレリンク(future板:443番)# Professor John Henry Holland
スレリンク(future板:205番)# KurasifaiaSisutemu
スレリンク(future板:192番)#196#200#210#217#241# KanniNyuuron
420:YAMAGUTIseisei~貸し
18/01/25 17:37:07.85 Ip52gDBro BE:44059829-2BP(3)
テンプレ漏れ
(強いAI)技術的特異点/シンギュラリティ 33
スレリンク(future板)
スレリンク(future板)
421:YAMAGUTIseisei
18/07/08 13:12:20.91 r8hmMT68N BE:9791322-2BP(3)
This is the html version of the file URLリンク(microsoft.com) .
Google automatically generates html versions of documents as we crawl the web.
Page 1
Dynamic Vectorization in the E2 Dynamic Multicore Architecture
To appear in the proceedings of HEART 2010
Andrew Putnam
Microsoft Research
anputnamATmicrosoft.
Aaron Smith
Microsoft Research
aasmithATmicrosoft.
Doug Burger
Microsoft Research
dburgerATmicrosoft.
ABSTRACT
Previous research has shown that Explicit Data Graph Execution (EDGE) instruction set architectures (ISA) allow for power efficient performance scaling.
In this paper we describe the preliminary design of a new dynamic multicore processor called E2 that utilizes an EDGE ISA to allow for the dynamic composition of physical cores into logical processors.
We provide details of E2 ' s support for dynamic reconfigurability and show how the EDGE ISA facilities out-of-order vector execution.
422:YAMAGUTIseisei
18/07/08 13:15:25.65 r8hmMT68N BE:58744883-2BP(3)
Categories and Subject Descriptors
C.1.2 [Computer Systems Organization]:
Multiple Data Stream Architectures --
single-instruction-stream, multiple-data-stream processors (SIMD), array and vector processors;
C.1.3 [Computer Systems Organization]:
Other Architecture Styles --
adaptable architectures, data-flow architectures
General Terms
Design, Performance
Keywords
Explicit Data Graph Execution (EDGE)
423:YAMAGUTIseisei
18/07/08 13:39:06.30 r8hmMT68N BE:137071687-2BP(3)
1.
INTRODUCTION
Chip designers have long relied on dynamic voltage and frequency scaling (DVFS) to trade off power for performance.
However, voltage scaling no longer works as processors approach the minimum threshold voltage (Vmin) as frequency scaling at Vmin reduces both power and performance linearly, achieving no reduction in energy.
Power and performance trade-offs are thus left to either the microarchitecture or the system software.
When designing an architecture with little (if any) DVFS, designers must choose how to spend the silicon resources.
Hill and Marty [6] described four ways that designers could use these resources:
(1)
many small, low performance, power efficient cores,
(2)
few large, power inefficient, high performance cores,
(3)
a heterogeneous mix of both small and large cores,
and (4)
a dynamic architecture capable of combining or splitting cores to adapt to a given workload.
Of these alternatives, the highest performance and most energy efficient design is the dynamic architecture.
Hill and Marty characterized what such a dynamic processor could do but did not describe the details of such an architecture.
TFlex [9] is one proposed architecture that demonstrated a large dynamic range of power and performance
by combining power efficient, lightweight processor cores into larger, more powerful cores through the use of an Explicit Data Graph Execution (EDGE) instruction set architecture (ISA).
TFlex is dynamically configurable to provide the same performance and energy efficiency as a small embedded processor or to provide the higher performance of an out-of-order superscalar on single-threaded applications.
Motivated by these promising results, we are currently designing a new dynamic architecture called E2 that utilizes an EDGE ISA to achieve high performance power efficiently [3].
The EDGE model divides a program into blocks of instructions that execute atomically.
424:YAMAGUTIseisei
18/07/08 13:40:25.59 r8hmMT68N BE:132176669-2BP(3)
Blocks consist of a sequence of dataflow instructions that explicitly encode relationships between producer-consumer instructions, rather than communicating through registers as done in a conventional ISA.
These explicit encodings are used to route operands to private reservation stations (called operand buffers) for each instruction.
Registers and memory are only used for handling less-frequent inter-block communication.
Prior dynamic architectures [7, 9] have demonstrated the ability to take advantage of task and thread-level parallelism, but handling data-level parallelism requires dividing data into independent sets and using thread-level parallelism.
In this paper we focus on efficiently exploiting data-level parallelism, even without threading, and present our preliminary vector unit design for E2.
Unlike previous in-order vector machines, E2 allows for out-of-order execution of both vectors and scalars.
The E2 instruction set and execution model supports three new capabilities that enable efficient vectorization across a broad range of codes.
First, by slicing up the statically programmed issue window into vector lanes, highly concurrent, out-of-order issue of mixed scalar and vector operations can be achieved with lower energy overhead than scalar mode.
Second, the statically allocated reservation stations permit the issue window to be treated as a vector register file, with wide fetches to memory and limited copying between a vector load and the vector operations.
Third, the atomic block-based model in E2 permits refreshing of vector (and scalar) instruction blocks mapped to reservation stations, enabling repeated vector operations to issue with no fetch or decode energy overhead after the first loop iteration.
Taken together, these optimizations will reduce the energy associated with finding and executing many sizes of vectors across a wide range of codes.
425:YAMAGUTIseisei
18/07/08 13:42:20.21 r8hmMT68N BE:117490368-2BP(3)
Page 2
ALU Instruction Window 32 x 54b
ALU Instruction Window 32 x 54b
ALU nstruction Window 32 x 54b
ALU Instruction Window 32 x 54b
L1 Instruction Cache 32 KB
L1 Data Cache 32 KB
Control
Branch Predictor
Registers [0-15] 16 x 64b Registers [16-31] 16 x 64b Registers [32-47] 16 x 64b Registers [48-63] 16 x 64b
Memory Interface Controller
Load/Store Queue
Operand Buffer 32 x 64b Operand Buffer 32 x 64b Operand Buffer 32 x 64b Operand Buffer 32 x 64b
Operand Buffer 32 x 64b Operand Buffer 32 x 64b Operand Buffer 32 x 64b Operand Buffer 32 x 64b
Lane 1 Lane 2 Lane 3 Lane 4
Core Core Core Core Core Core Core Core Core Core Core Core Core Core Core Core L2 L2 L2 L2
Core Core Core Core Core Core Core Core Core Core Core Core Core Core Core Core L2 L2 L2 L2
Figure 1:
E2 microarchitecture block diagram.
In vector mode, each core is composed of four independent vector lanes, each with a 32-instruction window, two 64-bit operand buffers, an ALU for both integer and floating point operations, and 16 registers.
In scalar mode, the ALUs in lanes 3 and 4 are powered down, and the instruction windows, operand buffers, and registers are made available to the other two lanes.
426:YAMAGUTIseisei
18/07/08 13:46:08.18 r8hmMT68N BE:58745546-2BP(3)
2.
THE E2 ARCHITECTURE
E2 is a tiled architecture that consists of low power, high performance, decentralized processing cores connected by an on-chip network.
This design provides E2 with the benefits of other tiled architectures - namely simplicity, scalability, and fault tolerance.
Figure 1 shows the basic architecture of an E2 processor containing 32 cores, and a block diagram of the internal structure of one physical core.
A core contains N lanes (in this paper we choose four), with each lane consisting of a 64-bit ALU and one bank of the instruction window, operand buffers, and register file.
ALUs support both integer and floating point operations, as well as fine-grained SIMD execution (eight 8-bit, four 16-bit, or two 32-bit integer operations per cycle, or two single-precision floating point calculations per cycle).
This innovation of breaking the window into lanes allows for high vector throughput with little additional hardware complexity.
E2 ' s EDGE ISA restricts blocks in several ways to simplify the hardware that maps blocks to the execution sub-strate and detect when blocks are finished executing.
Blocks are variable-size: they contain between 4 and 128 instructions and may execute at most 32 loads and stores.
The hardware relies on the compiler to break programs into blocks of dataflow instructions and assign load and store identifiers to enforce sequential memory semantics [12].
To improve performance, the compiler uses predication to form large blocks filled with useful instructions.
To simplify commit, the architecture relies on the compiler to ensure that a single branch is produced from every block, and to encode the register writes and the set of store identifiers used.
E2 cores operate in two execution modes: scalar mode and vector mode.
In scalar mode, any instruction can send operands to any other instruction in the block, and all but two of the ALUs are turned off to conserve power.
427:YAMAGUTIseisei
18/07/08 13:47:43.50 r8hmMT68N BE:36716235-2BP(3)
In vector mode, all N ALUs are turned on, but instructions can only send operands to instructions in the same vector lane.
The mode is determined on a per-block basis from a bit in the block header.
This allows each core to adapt quickly to different application phases on a block-by-block basis.
2.1
Composing Cores
One key characteristic that distinguishes E2 from other processors is the ability to dynamically adapt the architecture for a given workload by composing and decomposing cores.
Rather than fixing the size and number of cores at design time, one or more physical cores can be merged together at runtime to form larger, more powerful logical cores.
For example, serial portions of a workload can be handled by composing every physical core into one large logical processor that performs like an aggressive superscalar.
Or, when ample thread-level parallelism is available, the same large logical processor can be split so each physical processor can work independently and execute instruction blocks from independent threads.
Merging cores together is called composing cores, while splitting cores is called decomposing cores.
Logical cores interleave accesses to registers and memory among the physical cores to give the logical core the combined computational resources of all the composed physical cores.
For example, a logical core composed of two physical cores uses an additional bit of the address to choose between the two physical caches, effectively doubling the L1 cache capacity.
The register files are similarly interleaved, but since only 64 registers are supported by the ISA, the additional register file capacity is powered gated to reduce power consumption.
Each instruction block is mapped to a single physical processor.
428:YAMAGUTIseisei
18/07/08 14:00:29.11 r8hmMT68N BE:44059436-2BP(3)
Page 3
When composed, the architecture uses additional cores to execute speculative instruction blocks.
When the non-speculative block commits, it sends the commit signal along with the exit branch address to all other cores in the logical processor.
Speculative blocks on the correct path continue to execute, while blocks on non-taken paths are squashed.
Details of this process are discussed further in section 2.2.1.
Core composition is done only when the overhead of changing configurations is outweighed by the performance gains of a more efficient configuration.
Composition is always done at block boundaries and is initiated by the runtime system.
To increase the number of scenarios in which composition is beneficial, E2 provides two different ways to compose cores, each offering a different trade-off in overhead and efficiency.
Full composition changes the number of physical cores in a logical core, and changes the register file and cache mappings.
Dirty cache lines are written out to main memory lazily.
Logical registers and cache locations are distributed evenly throughout the physical cores.
Cache lines are mapped via a simple hash function, leading to a larger logical cache that is the sum of the cache capacities of all physical cores.
Quick composition adds additional cores to a logical processor, but retains the same L1 data cache and register mappings, and does not write dirty cache lines out to main memory.
This leaves the logical processor with a smaller data cache than possible with full composition, but ensures that accesses to data already in the cache will still hit after composing.
Quick composition is the most useful for short-lived bursts of activity where additional execution units are useful, but where the overhead of reconfiguring the caches is greater than the savings from a larger, more efficient cache configuration.
429:YAMAGUTIseisei
18/07/08 14:02:32.10 r8hmMT68N BE:137071687-2BP(3)
Decomposition removes physical cores from a logical processor and powers the removed cores down to conserve energy.
Execution continues on the remaining physical cores.
Decomposition requires flushing the dirty lines of each cache being dropped from the logical processor and updating the cache mapping.
Dirty cache lines in the remaining cores are written back only when a cache line is evicted.
2.2
Speculation
It has long been recognized that speculation is an essential piece of achieving good performance on serial workloads.
E2 makes aggressive use of speculation to improve performance.
A combined predicate-branch predictor [5] speculates at two levels.
First, it predicts the branch exit address for each block for speculation across blocks.
Second, it predicts the control flow path within blocks by predicting the predicate values.
2.2.1
Speculation Across Blocks
Predicting the branch exit address allows instruction blocks to be fetched and begin executing before the current block has completed.
The oldest instruction block is marked as non-speculative, and predicts a branch exit address.
This address is fetched and begins executing on another physical core in the logical processor or on the same physical core if there is available space in the instruction window.
The taken branch address often resolves before the block completes.
In this case, the non-speculative block notifies the other cores in the logical processor of the taken address.
The oldest instruction block then becomes the non-speculative block.
Any blocks that were not correctly speculated are squashed.
This taken branch signal differs from the commit signal.
The taken branch allows the next block to continue speculation and begin fetching new instruction blocks.
However, register and memory values are not valid until after the commit signal.
430:YAMAGUTIseisei
18/07/08 14:03:47.48 r8hmMT68N BE:102803876-2BP(3)
Component Parameters Area (mm2) % Area
Instruction Window 32x54b 0.08 2%
Branch Predictor 0.12 3%
Operand Buffers 32x64b 0.19 5%
ALUs 4 SIMD, Int+FP 0.77 20%
Register File 64 x 64b 0.08 2%
Load-Store Queue 0.19 5%
L1 I-Cache 32kB 1.08 28%
L1 D-Cache 32kB 1.08 28%
Control 0.19 5%
Core 3.87 100%
L2 Cache 4MB 100
Table 1:
E2 core components, design parameters, and area.
2.2.2
Speculation Within a Block
There are three types of speculation within an instruction block.
Predicate speculation uses the combined predicate-branch predictor to predict the value of predicates.
Memory speculation occurs in speculative blocks when the speculative block loads values from the L1 cache that may be changed by less-speculative blocks.
Load speculation occurs when the load-store queue (LSQ) allows loads to execute before stores with lower load-store identifiers have executed.
In all three cases, mis-speculation requires re-execution of the entire instruction block.
This is relatively lightweight and only requires invalidating the valid bits in all of the operand buffers, and re-loading the zero operand instructions.
431:YAMAGUTIseisei
18/07/08 14:34:47.53 r8hmMT68N BE:88117766-2BP(3)
3.3
Commit
During execution, instructions do not modify the architectural state.
Instead, all changes are buffered and commit together at block completion.
Once the core enters the commit phase, the register file is updated with all register writes, and all stores in the load-store queue are sent to the L1 cache beginning with the lowest sequence identifier.
Once all register writes and stores have committed, the core sends a commit signal to all other cores in the same logical processor.
3.3.1
Refresh
One important commit optimization, called refresh, occurs when the instruction block branches back to itself.
Rather than loading the instructions again from the L1 instruction cache, the instructions are left in place and only the valid bits in the operand buffers and load-store queues are cleared.
This allows the instruction fetch phase to be bypassed entirely.
Instructions that generate constants can also pin values in the operand buffers so that they remain valid after refresh, and are not regenerated each time the instruction block executes.
432:YAMAGUTIseisei
18/07/08 14:36:00.17 r8hmMT68N BE:119937877-2BP(3)
Page 4
Instructions Blocks of up to 128 instructions are fetched from the L1 instruction cache at a time and loaded into the instruction window.
Instructions remain resident in the window until block commit (or possibly longer, as described in section 3.3.1).
Physical cores support one 128-instruction block, two 64-instruction blocks, or four 32-instruction blocks in the window at the same time.
Instruction blocks begin with a 128-bit block header containing: the number of instructions in the block, flags for special block behavior, and bit vectors that encode the global registers written by the block and the store identifiers used.
Instructions are 32-bits wide, and generally contain at least four fields:
Opcode [9 bits]:
The instruction to execute along with the number of input operands to receive.
Predicate [2 bits]:
Indicates whether the instruction must wait on a predicate bit, and whether to execute if that bit is true or false.
Target 1 [9 bits]:
The identifier of the consumer for the instruction ' s result.
If the consumer is a register, this field is the register number.
If the consumer is another instruction, this field contains the consumer ' s instruction number (used as an index into the operand buffer) and whether the result is used as operand 0, operand 1, or as a predicate.
Target 2 / Immediate [9 bits]:
Either a second instruction target, or a constant value for immediate instructions.
The instruction window is divided into four equal banks with each bank loading two instructions per cycle.
Instructions that do not require input operands, such as constant generation instructions, are scheduled to execute immediately by pushing the instruction number onto the ready queue.
433:YAMAGUTIseisei
18/07/08 14:38:01.30 r8hmMT68N BE:176234898-2BP(3)
3.2
Execute
Execution starts by reading ready instruction numbers from the ready queues.
Operands, the opcode, and the instruction target fields are forwarded to either the ALUs, register file (for read instructions), or the load-store queue (for loads and stores).
The target field is used to route the results (if any) back to the appropriate operand buffer (or to the register file, in the case of writes).
When results are forwarded back to the operand buffers, the targeted instruction is checked to see which inputs are required, and which operands have already arrived.
If all operands for the instruction have arrived, the instruction number is added to the ready queue.
Execution continues in this data-driven manner until the block is complete.
Like other EDGE and dataflow architectures, special handling is required for loads and stores to ensure that memory operations follow the program order semantics of imperative language programs.
E2 uses the approach described in [10], where the compiler encodes each memory operation with a sequence identifier to denote program order that the microarchitecture uses to enforce sequential memory semantics.
Not all instructions in a block necessarily execute because of predication, so the microarchitecture must detect block completion.
Blocks are considered complete when (1) one (and only one) branch has executed, and (2) all instructions that modify external state (register writes and stores) have executed.
The compiler encodes the register writes and store identifiers in the instruction block header so that the microarchitecture can identify when criteria (2) is satisfied.
434:YAMAGUTIseisei
18/07/08 14:39:10.11 r8hmMT68N BE:19581942-2BP(3)
3.3
Commit
During execution, instructions do not modify the architectural state.
Instead, all changes are buffered and commit together at block completion.
Once the core enters the commit phase, the register file is updated with all register writes, and all stores in the load-store queue are sent to the L1 cache beginning with the lowest sequence identifier.
Once all register writes and stores have committed, the core sends a commit signal to all other cores in the same logical processor.
3.3.1
Refresh
One important commit optimization, called refresh, occurs when the instruction block branches back to itself.
Rather than loading the instructions again from the L1 instruction cache, the instructions are left in place and only the valid bits in the operand buffers and load-store queues are cleared.
This allows the instruction fetch phase to be bypassed entirely.
Instructions that generate constants can also pin values in the operand buffers so that they remain valid after refresh, and are not regenerated each time the instruction block executes.
Element Size Minimum (1 ALU) Maximum (4 ALUs)
8-bit 8 32
16-bit 4 16
32-bit 2 (1 single fp) 8 (4 single fp)
64-bit 1 4
Table 2:
Supported vector operations
435:YAMAGUTIseisei
18/07/08 14:39:52.51 r8hmMT68N BE:110147459-2BP(3)
3.4
Vector Mode
Vector mode execution divides each processor core into N (in this paper 4) independent vector lanes.
When operating in vector mode, instructions can only target other instructions in the same vector lane, eliminating the need for a full crossbar between operand buffers and ALUs.
Each lane consists of a 32-entry instruction window, two 64-bit operand buffers, 16 registers, and one ALU.
E2 supports vector operations on 64-bit, 128-bit (padded to 256-bits), and 256-bit wide vectors.
Each ALU supports eight 8-bit, four 16-bit, or two 32-bit vector operations.
Four ALUs enable E2 to support up to 32 vector operations per cycle per core.
64-bit vector operations utilize a single ALU, where as 128- and 256-bit vector operations utilize all four ALUs.
Table 2 lists the number of parallel vector operations supported for each vector length and data element size.
Instruction blocks containing vector instructions are limited to 32 instructions which is the size of the instruction window for each vector lane.
Vector instructions issuing in lane 1 are automatically issued in the other three lanes and scalar instructions are always assigned to lane 1.
In vector mode, the sixty-four 64-bit physical registers (R0 - R63) are aliased to form sixteen 256-bit vector registers (V0 - V15).
We divide the physical register file into four banks to support single cycle access for vectors.
3.4.1
Memory Access in Vector Mode
E2 cores operate on vectors in 256-bit chunks, which enables efficient exploitation of data-level parallelism on small and medium-length vectors.
Operating on larger vectors is done using multiple instruction blocks in a loop, using the efficient refresh mode to bypass instruction fetch and the generation of constants (section 3.3).
436:YAMAGUTIseisei
18/07/08 14:43:28.44 r8hmMT68N BE:34268827-2BP(3)
Page 5
Splitting larger vectors among multiple instruction blocks could introduce a delay between loads of adjacent chunks of the same vector, as those loads are split among multiple instruction blocks.
To mitigate this delay, E2 employs a specialized unit called the memory interface controller (MIC).
The MIC takes over control of the L1 data cache, changing part of the cache into a prefetching stream buffer [8,11].
Stream buffers predict the address of the next vector load and bring that data into the cache early.
This ensures that the vector loads in subsequent instruction blocks always hit in the L1 cache.
Since vector and scalar operations are mixed in instruction blocks, part of the cache still needs to operate as a traditional cache.
Rather than halve the size of the cache, the set associativity of the cache is cut in half ? converting those ways into the memory for a stream buffer.
On vector loads, the cache checks the stream buffer.
On scalar loads and stores, the cache checks the cache in the same manner, albeit with a reduced number of sets to check.
Vector store instructions are buffered in the stream buffer until block commit, at which point they are written directly out to main memory.
4.
EXAMPLE: RGB TO Y CONVERSION In this section we give an example to explain how a program is vectorized on E2.
Figure 2 shows the C code and corresponding vectorized assembly for a RGB to Y brightness conversion which is commonly used to convert color images to grayscale.
437:YAMAGUTIseisei
18/07/08 14:44:18.63 r8hmMT68N BE:22029833-2BP(3)
1 // numVectors > 0
2 // y = r * .299 + g * .587 + b * .114;
3 void rgb2y(int numVectors,
4 __vector float *r, __vector float *g,
5 __vector float *b, __vector float *y)
6 {
7 __vector float yr = { 0.299f, 0.299f,
8 0.299f, 0.299f };
9 __vector float yg = { 0.587f, 0.587f,
10 0.587f, 0.587f } ;
11 __vector float yb = { 0.114f, 0.114f,
12 0.114f, 0.114f };
13
14 for (int i = 0; i < numVectors; i++)
15 y[i] = r[i] * yr + g[i] * yg + b[i] * yb;
16 }
17
18 _rgb2y:
19 read t30, r3 // numVectors
20 read t20, r4 // address of next r
21 read t21, r5 // address of next g
22 read t22, r6 // address of next b
23 read t32, r7 // address of y
24 read t31, r8 // i
25 read t1, v0 // vector yr
26 read t3, v1 // vector yg
27 read t5, v2 // vector yb
28
438:YAMAGUTIseisei
18/07/08 14:44:48.60 r8hmMT68N BE:73431656-2BP(3)
29 // RGB to Y conversion
30 vl t0, t20 [0] // vector load
31 vl t2, t21 [1]
32 vl t4, t22 [2]
33 vfmul t6, t0, t1 // vector fp mul
34 vfmul t7, t2, t3
35 vfmul t8, t4, t5
36 vfadd t9, t6, t7 // vector fp add
37 vfadd t10, t8, t9
38
39 // store result in Y
40 multi t40, t31, #32
41 add t41, t32, t40
42 vs 0(t41), t10 [3] // vector store
43
44 // loop test
45 tlt t14, t31, t30
46 ret_t<t14>
47 br_f<t14> rgb2y
48 addi r8, t31, #1
49 addi r4, t20, #32
50 addi r5, t21, #32
51 addi r6, t22, #32
Figure 2:
C source code and E2 assembly listing for a vectorized RGB to Y brightness conversion.
439:YAMAGUTIseisei
18/07/08 14:46:52.36 r8hmMT68N BE:117490368-2BP(3)
Each pixel in an image has a triple corresponding to the red, green, and blue color components.
Brightness (Y) is computed by multiplying each RGB value by a constant and summing the three results.
This program can be trivially parallelized to perform multiple conversions in parallel since each conversion is independent.
4.1
C Source
Each RGB component is represented by a vector and pointers to these vectors, along with a pointer to the preallocated result vector Y, and the number of vectors to convert are passed to the function as arguments (lines 4-5).
The constants for the conversion are also stored in vectors (lines 7-12).
Each vector is 256-bits wide and the individual data elements are padded to 64-bits since their type is a 32-bit single precision float.
The conversion is done using a simple for loop (lines 14-16).
To simplify the example we do not unroll the loop to fill the block.
4.2
Assembly The assembly listing is given in lines 18-51.
Instructions are grouped into blocks by the compiler (one block for this example) and a new block begins at every label (line 18).
The architecture fetches, executes, and commits blocks atomically.
By convention we use Rn to denote scalar registers, Vn to denote vector registers, and Tn to denote temporary operands.
The scalar and vector registers are part of the global state visible to every block.
The temporary operands however are only visible within the block they are defined.
The only instructions that can read from the global register file are register READ instructions (lines 19-27).
However, most instructions can write to the global register file.
440:YAMAGUTIseisei
18/07/08 14:47:38.65 r8hmMT68N BE:176235089-2BP(3)
Vector instructions begin with ' v ' (lines 30-37 and 42).
All load and store instructions are assigned load-store identifiers to ensure sequential memory semantics (lines 30-32 and 42).
That is a load assigned ID0 must complete before a store with ID1.
Most instructions can be predicated and predicates are only visible within the block they are defined.
Predicated instructions take an operand representing true or false that is compared against the polarity encoded into the predicated instruction (denoted by _t and _f).
The test instruction in line 45 creates a predicate that the receiving instructions (lines 46-47) compare against their own encoded predicate.
Only instructions with matching predicates execute.
Blocks are limited to a maximum of 128 scalar instructions.
When using vector instructions blocks are limited to a total of 32 scalar and vector instructions.
Block _rgb2y contains a mix of 27 scalar and vector instructions.
441:YAMAGUTIseisei
18/07/08 14:48:24.34 r8hmMT68N BE:102804067-2BP(3)
Page 6
CYCLE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
FETCH IF IF IF IF
READ R R R R R
READ R R R R
MEM L L L S
EX A A A M M M M M M M M M A A B
EX M A T M M M M M M M M M A A A
EX M M M M M M M M M A A
EX M M M M M M M M M A A
Figure 3:
One possible schedule for Figure 2.
4.3
Instruction Schedule
Figure 3 gives one possible schedule for the example in Figure 2.
We assume a three cycle 32-bit floating point multiply, and that all loads hit in the L1 cache and require three cycles.
The architecture is capable of fetching eight instructions per cycle and thus requires four cycles to fetch the 27 instruction block.
In cycle one, eight register read instructions are fetched which are all available for execution in the following cycle since they have no dependencies.
Two register reads can execute per cycle requiring five cycles to read all the global registers.
In cycle two, registers R4 (line 20) and R8 (line 24) are read and the resulting data is sent to the vector load (line 30), multiply immediate (line 40), and add immediate (line 48) instructions.
Since each of these instructions is waiting on a single operand, they are now all ready and begin executing in cycle three.
Execution continues in this dataflow fashion until the block is ready to commit in cycle 17.
442:YAMAGUTIseisei
18/07/08 14:50:42.50 r8hmMT68N BE:78326584-2BP(3)
5.
CONCLUSION
In this paper we described the E2 architecture ? a new dynamic multicore utilizing an Explicit Data Graph Execution (EDGE) ISA, designed to achieve high performance power efficiently.
As an EDGE architecture, E2 efficiently exploits instruction-level parallelism through dataflow execution and aggressive speculation.
In addition, we have described how the architecture adapts to handle data-level parallelism through vector and SIMD support.
This vector support can be interspersed with scalar instructions, making E2 more flexible than traditional vector processors, and more capable than traditional scalar architectures.
We have developed an architectural simulator for E2 using SystemC and a new compiler backend with the Microsoft Phoenix software optimization and analysis framework [1].
We are currently developing a cycle accurate FPGA implementation that when combined with our industrial strength compiler, will allow us to perform a detailed exploration and evaluation of the architecture.
Many challenges lay ahead.
To be compelling as an accelerator, we must demonstrate that E2 provides better performance, power efficiency, and programmability than specialized accelerators such as GPUs and dedicated vector processors.
E2 may also excel as a general-purpose processor, in which case we must show that it provides compelling enough power/performance gains over current static multi-core architectures to justify a transition to a new ISA.
E2 ' s performance and power efficiency are built on its ability to compose and decompose cores dynamically, so the correct policies and mechanisms for managing dynamic composition will require careful consideration.
Ideally we would like to leave all decisions about composition to the runtime system, freeing the programmer completely from reasoning about the underlying hardware.
443:YAMAGUTIseisei
18/07/08 14:52:08.18 r8hmMT68N BE:48954645-2BP(3)
Finally, there is a wide variety of application domains where E2 ' s ability to trade-off power and performance could be useful, ranging from embedded devices to the data center.
In the months ahead we plan to examine a diverse set of work-loads and investigate how broadly an E2 processor can span the power-performance spectrum.
6.
REFERENCES
[1] Microsoft Phoenix.
URLリンク(research.microsoft.com)
[2] ARM. Cortex-A9 MPCore technical reference manual, November 2009.
[3] D. Burger, S. W. Keckler, K. S. McKinley, M. Dahlin, L. K. John, C. Lin, C. R. Moore, J. Burrill, R. G. McDonald, W. Yoder, and the TRIPS Team.
Scaling to the End of Silicon with EDGE architectures.
IEEE Computer, 37(7):44?55, July 2004.
[4] Cadence. Cadence InCyte Chip Estimator, September 2009.
[5] H. Esmaeilzadeh and D. Burger.
Hierarchical control prediction: Support for aggressive predication.
In Proceedings of the 2009 Workshop on Parallel Execution of Sequential Programs on Multi-core Architectures, 2009.
[6] M. D. Hill and M. R. Marty.
Amdahl ' s law in the multicore era.
IEEE COMPUTER, 2008.
[7] E. ?Ipek, M. K?rman, N. K?rman, and J. F. Mart?ez.
Core Fusion: Accommodating software diversity in chip multiprocessors.
In International Symposium on Computer Architecture (ISCA), San Diego, CA, June 2007.
[8] N. P. Jouppi.
Improving direct-mapped cache performance by the addition of a small fully-associative cache and prefetch buffers.
SIGARCH Computer Architecture News, 18(3a), 1990.
[9] C. Kim, S. Sethumadhavan, D. Gulati, D. Burger, M. Govindan, N. Ranganathan, and S. Keckler.
Composable lightweight processors.
In Proceedings of the 40th Annual IEEE/ACM International Symposium on Microarchitecture, 2007.
444:YAMAGUTIseisei
18/07/08 14:52:51.19 r8hmMT68N BE:58745546-2BP(3)
[10] S. Sethumadhavan, F. Roesner, J. S. Emer, D. Burger, and S. W. Keckler.
Late-binding: enabling unordered load-store queues.
In Proceedings of the 34th Annual International Symposium on Computer Architecture, pages 347?357, New York, NY, USA, 2007.
ACM.
[11] T. Sherwood, S. Sair, and B. Calder.
Predictor-directed stream buffers.
In Proceedings of the 33rd Annual ACM/IEEE International Symposium on Microarchitecture, 2000.
[12] A. Smith. Explicit Data Graph Compilation.
PhD thesis, The University of Texas at Austin, 2009.
445:YAMAGUTIseisei
18/07/15 06:07:49.01 9zKPYUy8Y BE:24477825-2BP(3)
>>431
訂正 Page 3 ( 重複 >>434 )
2.3
Area and Frequency
We developed an area model for the E2 processor using ChipEstimate InCyte [4] and an industry-average 65nm process technology library.
The design parameters and component areas are shown in Table 1.
Each E2 core requires 3.87 mm2, including L1 caches.
Frequency estimates are not available using our version of InCyte.
However, the microarchitecture does not have any large, global structures and uses distributed control through-out the chip.
Because of this, we expect that E2 will achieve a comparable frequency to standard cell ARM multi-core processor designs, which range from 600 to 1000 MHz in 65nm [2].
3.
EXECUTION PIPELINE
E2 ' s execution is broken into three primary stages: instruction fetch, execute, and commit.
This section first describes the behavior of each stage when operating in scalar mode, then describes the differences between scalar and vector mode.
3.1
Fetch
One of the primary differences between E2 and conventional architectures is that E2 fetches many instructions at once, rather than continually fetching single instructions.
446:YAMAGUTIseisei
18/08/06 00:48:14.81 FnAR0u04o BE:88117294-2BP(3)
arXiv:1803.06617v1 [cs.AR] 18 Mar 2018
Microsoft Research Technical Report
Authored January 2014; Released March 2018
Towards an Area-Efficient Implementation of a High ILP EDGE Soft Processor
Jan Gray
Gray Research LLC
jsgray@acm.org
Aaron Smith
Microsoft Research
aaron.smith@microsoft.com
Abstract―
In-order scalar RISC architectures have been the dominant paradigm in FPGA soft processor design for twenty years.
Prior out-of-order superscalar implementations have not exhibited competitive area or absolute performance.
This paper describes a new way to build fast and area-efficient out-of-order superscalar soft processors by utilizing an Explicit Data Graph Execution (EDGE) instruction set architecture.
By carefully mapping the EDGE microarchitecture, and in particular, its dataflow instruction scheduler, we demonstrate the feasibility of an out-of-order FPGA architecture.
Two scheduler design alternatives are compared.
Index Terms―
Explicit Data Graph Execution (EDGE);
hybrid von-Neumann dataflow;
FPGA soft processors
447:YAMAGUTIseisei
18/08/06 00:54:39.80 FnAR0u04o BE:137071687-2BP(3)
INTRODUCTION
Design productivity is still a challenge for reconfigurable computing.
It is expensive to port workloads into gates and to endure 102 to 104 second bitstream rebuild design iterations.
Soft processor array overlays can help mitigate these costs.
The costly initial port becomes a simple cross-compile targeting the soft processors, and most design turns are quick recompiles.
Application bottlenecks can then be offloaded to custom hardware exposed as new instructions, function units, autonomous accelerators, memories, or interconnects.
The advent of heterogeneous FPGAs with hard ARM cores does not diminish the complementary utility of soft cores.
As FPGAs double in capacity, potential soft processors per FPGA also doubles.
A mid-range FPGA can now host many hundreds of soft processors and their memory interconnection network, and such massively parallel processor and accelerator arrays (MPPAAs) can sustain hundreds of memory accesses and branches per cycle --
throughput that a few hard processors cannot match.
The microarchitectures of general purpose soft processors have changed little in two decades.
Philip Freidin's 16-bit RISC4005 (1991) was an in-order pipelined scalar RISC, as were j32, xr16, NIOS, and MicroBlaze [1]–[4], and as are their latest versions.
Over the years soft processors have gained caches, branch predictors, and other structures for boosting instruction level parallelism, but the basic scalar RISC microarchitecture still dominates.
This reflects a good fit between this simple microarchitecture and the FPGA primitive elements required to implement it -- particularly LUTs and one write/cycle LUT RAMs.
Unfortunately when such architectures take a cache miss, execution stops dead.
448:YAMAGUTIseisei
18/08/06 00:56:08.62 FnAR0u04o BE:68535874-2BP(3)
Design studies targeting higher instruction level parallelism (ILP) microarchitectures typically implement VLIW [5], [6] or vector [7], [8] architectures instead of out-of-order (OoO) [9]– [11] soft processor cores.
The problem with superscalar OoO microarchitectures is the complexity of the machinery needed to rename registers, schedule instructions in dataflow order, clean up after mispeculation, and retire results in-order for precise exceptions.
This in turn requires expensive circuits such as deep many-ported register files, many-ported CAMs for dataflow instruction scheduling wakeup, and many wide bus multiplexers and bypass networks, all of which are area intensive in FPGAs.
For example, multi-read, multi-write RAMs require a mix of replication, multi-cycle operation, clock doubling, bank interleaving, live-value-tables, and other expensive techniques.
The present work is a new approach to build high ILP OoO superscalar soft processors without most of the complexity and overhead.
Our insight is to implement an Explicit Data Graph Execution (EDGE) [12], [13] instruction set architecture designed for area and energy efficient high ILP execution.
1
Together the EDGE architecture and its compiler finesse away much of the register renaming, CAMs, and complexity, enabling an out-of-order processor for only a few hundred LUTs more than an in-order scalar RISC.
This paper explores how an EDGE ISA and FPGA optimized EDGE microarchitecture compare to in-order RISCs common on FPGAs today.
The key challenge, and the main contribution of the paper, is how to build a small, fast dataflow instruction scheduler in an FPGA.
We develop and contrast two alternative FPGA implementations on our way to developing a minimal-area EDGE soft processor.
449:YAMAGUTIseisei
18/08/06 00:57:07.53 FnAR0u04o BE:137071687-2BP(3)
z = x + y;
if (z <= 5) {
x=R0, y=R7
HEADER
I[0] READ R0 T[2R]
I[1] READ R7 T[2L]
I[2] ADD T[3L]
I[3] TLEI #5 B[1P]
I[4] BRO.T B1
I[5] BRO.F B1
↓
x += 1;
y -= 1;
x /= y;
HEADER
I[0] READ R0 T[2L]
I[1] READ R7 T[3L]
I[2] ADD #1 T[4L]
I[3] SUB #1 T[4R]
I[4] DIV W[R0]
I[5] BRO
}
450:YAMAGUTIseisei
18/08/06 00:58:15.18 FnAR0u04o BE:117490368-2BP(3)
INSTRUCTION WINDOW
OPERAND BUFFERS BP 0 1
READ R0
2R
READ R7
2L
ADD
3L
TLEI #5
BRO.T
BRO.F
Fig. 1:
Psuedo code and corresponding instruction block.
451:YAMAGUTIseisei
18/08/06 01:00:51.33 FnAR0u04o BE:137071687-2BP(3)
7b 2b 2b 3b 9b 9b
OPCODE PR BID XOP TARGET1 TARGET0
PR=
PREDICATE
BID=
BROADCAST ID
XOP=
EXTENDED OPCODE
Fig. 2:
General instruction format
452:YAMAGUTIseisei
18/08/06 01:06:59.49 FnAR0u04o BE:73431465-2BP(3)
II.
EDGE OVERVIEW
EDGE architectures [12], [14]–[16] execute instructions organized within instruction blocks that are fetched, executed, and committed atomically.
Instructions inside blocks execute in dataflow order, which removes the need for expensive register renaming and provides power efficient out-of-order execution.
The compiler explicitly encodes the data dependencies through the instruction set architecture, freeing the microarchitecture from rediscovering these dependencies at runtime.
Using predication, all intra-block branches are converted to dataflow instructions, and all dependencies other than memory are direct data dependencies.
This target form encoding allows instructions within a block to communicate their operands directly via operand buffers, reducing the number of accesses to a power hungry multi-ported physical register file.
Between blocks, instructions communicate using memory and registers.
By utilizing a hybrid dataflow execution model, EDGE architectures still support imperative programming languages and sequential memory semantics, but reap the benefits of outof-order execution with near in-order power efficiency and complexity.
Figure 1 shows an example of two EDGE instruction blocks and how instructions explicitly encode their targets.
In this example each block corresponds to a basic block.
The first two READ instructions target the left (T[2L]) and right (T[2R]) operands of the ADD instruction.
A READ is the only instruction that reads from the global register file (however any instruction may target, i.e.
write to, the global register file).
When the ADD receives the result of both register reads it will become ready and execute.
453:YAMAGUTIseisei
18/08/06 01:07:39.23 FnAR0u04o BE:51401873-2BP(3)
Figure 2 shows the general instruction format.
Each EDGE instruction is 32 bits and supports encoding up to two target instructions.
For instructions with more consumers than target fields, the compiler can build a fanout tree using move instructions or it can can assign high fanout instructions to broadcasts [15].
Broadcasts support sending an operand over a lightweight network to any number of consumer instructions in a block.
In Figure 1, when the TLEI (test-less-than-equalimmediate) instruction receives its single input operand from the ADD it will become ready and execute.
The test then produces a predicate operand that is broadcast on channel one (B[1P]) to all instructions listening on the broadcast channel, which in this example are the two predicated branch instructions (BRO.T and BRO.F).
The branch that receives a matching predicate will fire.
A spectrum of EDGE implementations are possible with various area and performance tradeoffs.
Prior EDGE research studied very wide issue implementations [12], [13], as well as fusion of multiple cores [14]–[16] to boost performance on scalar workloads.
In this work we focus on MPPAA scenarios utilizing compact EDGE soft processors with competitive performance/area.
Therefore data and pointers are 32 bits; blocks can be up to 32 instructions long; and the microarchitecture decodes 1-2 instructions per clock and issues one.
We further restrict the load-store queue (LSQ) in this study to a simple, non-speculative design and omit branch or memory dependence prediction.
454:YAMAGUTIseisei
18/08/06 01:09:57.45 FnAR0u04o BE:44059436-2BP(3)
III.
EDGE IN AN FPGA
IF
INSN CACHE DATA
nK x 32 x 2 ports
BLOCK RAM
DC
DECODER(S)
IS
INSTRUCTION WINDOW
INSN SCHEDULER
32 ENTRIES
T1 T0 IID
DECODED INSNS
32 x n LUT-RAM(S)
OPERAND BUFFERS
32 x 32 LUT-RAMS
455:YAMAGUTIseisei
18/08/06 01:11:14.79 FnAR0u04o BE:29373326-2BP(3)
EX
EX PIPELINE REGS
EX
TS
OPS0
32x32
×
LS
LOAD/STORE
QUEUE
DATA CACHE DATA
nK x 32
BLOCK RAM
LS PIPELINE REGS
×2
REGISTER FILE
32 x 32 LUT-RAM
Fig. 3:
Two decode, single issue EDGE microarchitecture.
456:YAMAGUTIseisei
18/08/06 01:14:03.00 FnAR0u04o BE:198264299-2BP(3)
A.
Microarchitecture
Figure 3 is an example microarchitecure for a compact EDGE processor.
It has much in common with a conventional in-order scalar RISC: instruction and data caches and a five stage pipeline including instruction fetch (IF), decode (DC), operand fetch, execute (EX), and memory/data cache access (LS).
Unlike an in-order processor, instruction operands are read from operand buffers, not the register file; and the instruction to execute next, in dataflow order, is determined by the IS (issue) pipeline stage.
This employs an instruction window comprising a dataflow instruction scheduler, a decoded instructions buffer, and operand buffers.
It uses a simple loadstore queue to issue memory instructions in program order.
The front end (IF, DC) runs decoupled from the back end (IS, EX, LS).
It fetches and decodes two instructions per clock into the instruction window.
The instruction window's dataflow scheduler keeps the ready state of each decoded instruction's inputs i.e.
its predication and operands.
When all of its inputs (if any) are ready, the instruction wakes up and is ready to issue.
The lowest numbered ready instruction IID is selected each cycle and its decoded instruction and input operands are read.
Besides the data mux and function unit control signals, this instruction encodes up to two ready events.
The scheduler accepts these and/or events from other sources (muxed into T0 and T1) and updates the ready state of other instructions in the window.
Thus dataflow execution proceeds, starting with the block's ready 0-input instructions, then instructions that these target, and so forth.
457:YAMAGUTIseisei
18/08/06 01:16:14.13 FnAR0u04o BE:154205879-2BP(3)
B.
EDGE dataflow instruction scheduling requirements
The instruction window and scheduler are the linchpin of the core.
Their area, clock period, capabilities, and limitations largely determine the realized performance of an EDGE core and the throughput of an EDGE multiprocessor.
The instruction scheduler has diverse functionality and requirements.
It is highly concurrent.
Each cycle the decoder(s) write instructions' decoded ready state and decoded instructions into the window.
Each cycle the scheduler selects the next instruction to issue, and in response the back end sends ready events --
either target ready events targeting a specific instruction's input slot (predicate, operand #0, operand #1) or broadcast ready events targeting all instructions waiting on a broadcast ID.
These set per-instruction active ready state bits which together with the decoded ready state may signal that the instruction is ready to issue.
Note the scheduler sometimes accepts events for target instructions which have not yet been decoded and must also inhibit reissue of issued ready instructions.
EDGE instructions may be non-predicated, or predicated true or false.
A predicated instruction does not become ready until it is targeted by another instruction's predicate result, and that result matches the predicate condition.
If the predicate doesn't match, the instruction never issues.
2
458:YAMAGUTIseisei
18/08/06 01:19:27.57 FnAR0u04o BE:24477252-2BP(3)
On branch to a new block all instruction window ready state is flash cleared (block reset).
However when a block branches back to itself (block refresh) only active ready state is cleared; the decoded ready state is preserved so that it is not necessary to re-fetch and decode the block's instructions.
Refresh is key to saving time and energy in loops.
Since some software critical paths consist of a single chain of dependent instructions, i.e.
A targets B targets C, it is important that the dataflow scheduler add no pipeline bubbles for successive back-to-back instruction wakeup.
Therefore the IS-stage ready-issue-target-ready pipeline recurrence should complete in one cycle – assuming this does not severely impact clock frequency.
Instructions such as ADD have a latency of one cycle.
With EX-stage result forwarding the scheduler can wake their targets' instructions in the IS-stage, even before the instruction completes.
Other instruction results may await ALU comparisons, take multiple cycles, or have unknown latency.
These must wait until later to wake their targets.
Finally, the scheduler design should be scalable across a spectrum of anticipated EDGE implementations – each cycle accepting at least 1-4 decoded instructions and 2-4 target ready events, and issuing 1-2 instructions per cycle.
We consider two alternative dataflow instruction scheduler designs:
a brute-force parallel scheduler, where instructions' ready state is explicily represented in FPGA D-flip-flops (FFs), in which the ready status of every instruction is reevaluated each cycle;
and a more compact incremental scheduler which keeps ready state in LUT RAM and which updates ready status of only 2-4 target instructions per cycle.
459:YAMAGUTIseisei
18/08/06 01:20:35.82 FnAR0u04o BE:73431465-2BP(3)
C.
A parallel instruction scheduler
BID
T1
T0
ENs
31
...
3
DBID DRT DRF DR0 DR1
NEXT RDYS
RDY RT RF R0 R1 INH
2
1
0
DEC.RDYS
RESET
RESET REFRESH
32→(5,1)
PRIORITY ENCODER
IID,V
Fig. 4:
Block diagram of a parallel dataflow scheduler, with entry #2 shown in more detail.
460:YAMAGUTIseisei
18/08/06 01:22:51.58 FnAR0u04o BE:48954454-2BP(3)
Figure 4 depicts a parallel instruction scheduler for the instruction window of Figure 3.
Note the active ready state is set by target ready events T0, T1 and broadcast ID BID (if any), qualified by various input type enables ENs.
For a 32-entry window there are 32 instances of a one-instruction ready circuit.
In any cycle one or more of the 32 RDY signals may be asserted.
A 32-bit priority encoder reduces this to the 5-bit IID of the next instruction to issue.
For each entry there are six bits of decoded ready state,
i.e. they are initialized by the instruction decoder:
• DBID: 2-bit binary broadcast ID, or 00 if none
• DRT, DRF: decoder: predicate true (false) is ready
• DR0, DR1: decoder: operand #0 (operand #1) is ready
Together these bits encode whether the instruction has been decoded, awaits a predicate and/or some operand(s), perhaps via a broadcast channel, or is immediately ready to issue.
These bits are cleared on block reset only.
There are also six bits of active ready state: :
• RT, RF: predicate true (false) is ready
• R0, R1: operand #0 (operand #1) is ready
• INH: inhibit instruction – it has already issued
• RDY: instruction is ready to issue
3
461:YAMAGUTIseisei
18/08/06 01:25:56.54 FnAR0u04o BE:22029833-2BP(3)
An instruction is ready iff (RT & RF & R0 & R1 & ~INH).
Any of RT, RF, R0, R1 may be set when:
its corresponding DRX is set by the decoder, or
an executing instruction targets that input, explicitly, or via a broadcast event (broadcast ID, input).
Active ready state bits are cleared on block reset or refresh.
Decoded ready state Active ready state
Instruction DBID DRT DRF DR0 DR1 RT RF R0 R1 INH RDY
READ 00 1 1 1 1 1 1 1 1 1 0
READ 00 1 1 1 1 1 1 1 1 0 1
ADD 00 1 1 0 0 1 1 1 0 0 0
TLEI 00 1 1 0 1 1 1 0 1 0 0
BRO.T B1 01 0 1 1 1 0 1 1 1 0 0
BRO.F B1 01 1 0 1 1 1 0 1 1 0 0
undecoded 00 0 0 x x 0 0 x x x 0
TABLE I: Example Instruction Scheduler Ready State
462:YAMAGUTIseisei
18/08/06 01:28:42.21 FnAR0u04o BE:19582324-2BP(3)
Table I depicts a block's instruction scheduler state after decoding six instructions and issuing the first.
The first four non-predicated instructions have DRT and DRF set reflecting that they do not await any particular predicate results.
The two READ instructions, unpredicated and with zero input operands, are immediately ready to issue.
The first has issued – and so is now inhibited from reissue – targeting operand 0 of the ADD, whose R0 is now set.
The second READ will issue in the next IS pipeline cycle.
The TLEI (test-lessthan-or-equal-immediate) instruction broadcasts its predicate outcome on channel 1; the two branch instructions, predicated true (resp.
false), await this predicate result.
The seventh entry has not been decoded: (DRT|DRF)=0.
To reduce the critical path of dataflow scheduling, the front end writes predecoded EDGE instructions into the decoded instructions buffer.
As instruction IID issues, its decoded instruction is read by the back end.
Amongst other things it contains two target operand ready event fields, _T0 and _T1, which designate the 0-2 (IID, input) explicit targets of the instruction, as well as a 4-bit vector of input enables: ENs={RT EN, RF EN, R0 EN, R1 EN}.
Referring back to Figure 3, these signals are muxed with ready events from other pipeline stages into T0 and T1 input by the scheduler.
463:YAMAGUTIseisei
18/08/06 01:36:06.91 FnAR0u04o BE:132176669-2BP(3)
>>459
Therefore the IS-stage ready-issue-target-ready pipeline recurrence should complete in one cycle -- assuming this does not severely impact clock frequency.
Finally, the scheduler design should be scalable across a spectrum of anticipated EDGE implementations -- each cycle accepting at least 1-4 decoded instructions and 2-4 target ready events, and issuing 1-2 instructions per cycle.
>>490
inhibit instruction -- it has already issued
464:YAMAGUTIseisei
18/08/06 01:38:44.60 FnAR0u04o BE:44058492-2BP(3)
>>462
The first has issued -- and so is now inhibited from reissue -- targeting operand 0 of the ADD, whose R0 is now set.
465:YAMAGUTIseisei
18/08/06 01:41:18.68 FnAR0u04o BE:36716235-2BP(3)
D.
FPGA implementation of the parallel scheduler
Careful attention to FPGA circuit design is required to minimize the area and clock period of the scheduler.
The 32instruction window requires 32*(6+6)=384 FFs for the ready state, and 32*many LUTs to decode ready events and update each entry's ready state.
A modern FPGA packs a set of LUTs (lookup tables) and D-flip-flops (FFs) together into a logic cluster.
For example, Xilinx 7 series devices group four 6-LUTs and eight FFs into each ``slice'' cluster.
Each LUT has two outputs and may be used as one 6-LUT, or two 5-LUTs with five common inputs.
Each output may be registered in a FF.
The flip-flops have optional CE (clock enable) and SR (set/reset) inputs but these signals are common to all eight FFs in the cluster.
This basic cluster architecture is similar in Altera FPGAs.
From this follows two design considerations.
Fracturable 6-LUT decoders: For target instruction index decoding, so long as indices are ≤5 bits, two decoders may fit into a single 6-LUT.
Slice FF packing and cluster control set restrictions: To minimize area and wire delays, the design packs the ready state FFs densely, 4-8 FFs per cluster.
Every 6-bit decoded ready state entry is written together (common RST and CE) and can pack into one or two slices.
More care is required for the active ready state FFs.
Each of these 32*6=192 FFs may be individually set, but by packing four FFs per slice, when one FF is clock enabled, all are clock enabled.
Whenever a FF is set by a ready event the other FFs in its slice should not change.
This requires implementing CE functionality in each FF's input LUT, feeding back its output into its input: FF NXT = FF | (EN & input).
466:YAMAGUTIseisei
18/08/06 01:42:14.67 FnAR0u04o BE:132176669-2BP(3)
generate for (i = 0; i < N; i = i + 1) begin: R
always @* begin
// target decoders
T00[i] = T0 == i;
T01[i] = T0 == (i|N);
T10[i] = T1 == i;
T11[i] = T1 == (i|N);
B[i] = BID == DBID[i];
// next active ready state logic
RT_NXT[i] = RT[i] | DRT[i]
| (RT_EN & (T01[i]|T11[i]|B[i]));
RF_NXT[i] = RF[i] | DRF[i]
| (RF_EN & (T00[i]|T10[i]|B[i]));
R0_NXT[i] = R0[i] | DR0[i]
| (R0_EN & (T00[i]|T10[i]|B[i]));
R1_NXT[i] = R1[i] | DR1[i]
| (R1_EN & (T01[i]|T11[i]|B[i]));
INH_NXT[i] = INH[i] | (INH_EN & (IID == i));
RDY_NXT[i] = RT_NXT[i] & RF_NXT[i] & R0_NXT[i]
& R1_NXT[i] & ~INH_NXT[i];
end
end endgenerate
Listing 1: Parallel scheduler ``next readys'' logic
467:YAMAGUTIseisei
18/08/06 01:46:49.27 FnAR0u04o BE:73431465-2BP(3)
Listing 1 is Verilog that generates the ``next readys'' for an N-entry parallel scheduler.
Although there are four ready event input types (predicate true, false, operand #0, operand #1),
by ensuring that predicate target events never occur in the same cycle as operand target events, a single target index bit suffices to distinguish false/operand #0 targets from true/operand #1 targets.
(Further decoding is provided by specific {RT/RF/R0/R1} ENs enables.) Therefore for an instruction window with N=32 entries, T0 and T1 are six bits {input#:1; IID:5}.
The target decoders T00, T01, T10, T11 (target-0input-0, etc.) are each one 6-LUT, as is the broadcast select decoder B.
The next active ready state logic folds together the target decoder outputs with current active and decoded ready state.
This requires another seven LUTs (two for INH NXT), for a total of 32*12 = 384 LUTs.
This may be improved by splitting the 32-entry scheduler into two 16-entry banks of even and odd instructions.
Within a bank a 4-bit bank-IID suffices.
Then T0, T1 narrow to five bits so T00, T01, T10, T11 fit in two 5,5-LUTs, and INH NXT in one 6-LUT, or 2*16*(3+6)=288 LUTs in all.
468:YAMAGUTIseisei
18/08/06 01:51:35.42 FnAR0u04o BE:176234898-2BP(3)
>>467
4
469:YAMAGUTIseisei
18/08/06 01:56:04.52 FnAR0u04o BE:110146695-2BP(3)
Besides shaving LUTs, a two bank scheduler provides two sets of T0, T1 ports and can sink two sets of two events each cycle.
This is essential to sustain wider issue rates of two instructions per cycle (which may target four operands per cycle).
Yet-wider issue and yet-larger instruction windows may even merit a four bank design.
The ready-issue-target-ready scheduling recurrence is the critical path of the IS-stage.
A 32→5 priority encoder reduces the RDY vector to an IID which selects the decoded instruction.
The decoded instruction's fields { T0, T1, BID, ENs} are muxed into {T0,T1,BID,ENs} which update target instructions' ready state, including RDY.
Priority encoder: Many 32-bit encoder designs were evaluated, including onehot conversion with LUT or carry-logic or-trees, carry-logic zero-scan, and F7MAP/F8MAP muxes.
The present design uses two 16→4 encoders, one per bank, which complete in two LUT delays.
In a one-issue processor, a subsequent 2:1 mux selects one of these encoder outputs.
In particular each 16-bit encoder input I[15:0] is chunked into I[15], I[14:10], I[9:5], I[4:0].
Each 5-bit group indexes a 32x4 LUT ROM with the precomputed encoder output for that group.
Together with three 5-bit zero comparator outputs, these feed a custom 4-bit 3:1 selector which outputs 'b1111 when all three groups are zero.
Technology mapping and floorplanning:
The design uses an RPM (relationally placed macro) methodology to improve area and interconnect delays and achieve a repeatable layout for easy routing and timing closure under module composition and massive replication.
Structural RTL instantiates modules and tiles them into a scheduler.
The XST annotation (*LUT MAP="yes"*) on a ≤6-input module locks its logic to one LUT; (*RLOC="XxYy"*) packs FPGA primitives into clusters and places clusters relative to each other.
470:YAMAGUTIseisei
18/08/06 01:57:08.33 FnAR0u04o BE:132176096-2BP(3)
Fig. 5:
FPGA implementation of the parallel scheduler
Figure 5 is a Xilinx 7-series implementation of Figure 4, including the scheduler, priority encoder, and decoded instruction buffer, with the critical path highlighted in white.
Each two horizontal rows of FPGA slices correspond to four entries in the instruction window.
Left to right are:
• pale yellow: four 6-bit decoded ready state flip-flops;
• yellow/green: B, T00, T01, T10, T11 target decoders;
• orange: active ready state LUTs/FFs RT NXT/RT, etc.;
• purple: INH NXT and INH; • red: RDY NXT and RDY.
To the right are the synthesized priority encoders and muxes (blue) and the decoded instructions buffer (white) implemented in several 32x6-bit true dual port LUT RAMs.
Performance: In a Kintex-7 -1-speed grade, the critical path takes 5.0 ns, including RDY clock-to-out, priority encoder, mux, decoded instructions LUT RAM, next readys logic and RDY setup.
Interconnect delay is 85% of the critical path -- unfortunately all paths from any RDY to any RDY must traverse a relatively large diameter netlist.
Cycle time may be reduced to 2.9 ns by adding a pipeline register halfway through the scheduler critical path (the output port of the instruction buffer LUT RAM)
however this will not achieve back-to-back issue (in successive cycles) of a single dependent chain of instructions.
471:YAMAGUTIseisei
18/08/06 02:01:58.00 FnAR0u04o BE:132176096-2BP(3)
E.
Incremental dataflow scheduler ready state
The parallel scheduler is straightforward but it consumes hundreds of LUTs and FFs just to maintain 32x12b of ready state -- a few LUTs worth of LUT RAM -- and this area doubles as the instruction window size doubles.
Also, each cycle its next readys LUTs recompute the readiness of every instruction, even though (broadcast notwithstanding) each issued instruction affects at most two others' ready state.
In contrast, the incremental scheduler keeps decoded and active ready state in LUT RAM, maintains the frontier of ready instructions in queues, and evaluates the ready status of just 2-4 target instructions per cycle.
5
Compared to an array of FFs, LUT RAM is fast and dense but has some shortcomings: there is no way to flash clear it, and it only supports one write per cycle.
472:YAMAGUTIseisei
18/08/06 02:04:55.29 FnAR0u04o BE:29372843-2BP(3)
DRDYSS
WA ← DC_IID
RA ← EVT_IID
I ← DC_DRDYS
O → READY LOGIC DRDYS
ARDYSS
WA ← EVT_IID
RA ← EVT_IID
I ← READYLOGIC ARDYS_NXT
O → READYLOGIC DRDYS
DVS ← RESET
O → READYLOGIC DV
WA ← DRDYSS WA
RA ← DRDYSS RA
AVS ← RESETvREFRESH
WA ← ARDYSS WA
RA ← ARDYSS RA
O → READYLOGIC AV
READY LOGIC
READY →
DV ← DVS O
DRDYS ← DRDYSS O
AV ← AVS O
ARDYS → ARDYSS O
ARDYS_NXT → ARDYSS I
EVT_RDYS ← EVT_RDYS
(a) Design: ready state, validation, and ready logic.
473:YAMAGUTIseisei
18/08/06 02:07:43.81 FnAR0u04o BE:110147459-2BP(3)
(b) FPGA implementation.
Fig. 6:
A 16-entry scheduler bank.
474:YAMAGUTIseisei
18/08/06 02:09:43.22 FnAR0u04o BE:44058863-2BP(3)
// ready logic
always @* begin
ARDYS_NXT = (DV ? DRDYS : 4'b0000)
| (AV ? ARDYS : 4'b0000)
| EVT_RDYS;
READY = &ADRYS_NXT;
end
Listing 2: Ready logic
475:YAMAGUTIseisei
18/08/06 02:12:33.24 FnAR0u04o BE:48954454-2BP(3)
Instead, the scheduler uses a hybrid of LUT RAM and FF ``RAM''.
Decoded (DRT, DRF, DR0, DR1) and active (RT, RF, R0, R1) ready state are stored in several banks of 16x4 true dual port LUT RAM, which is validated by a 16x1 flashclearable-set-only-RAM ``FC-SO-RAM''.
This comprises 16 FFs (with common reset), 16 write port address decoders (eight 5,5-LUTs), and a 16:1 read port mux (four 6-LUTs, two MUXF7s, one MUXF8) -- just three slices in all.
Each read from this hybrid reads the 4b LUT RAM entry and its valid bit.
Each write updates the LUT RAM and sets its valid bit.
Multiple LUT RAM write ports.
To sustain a fetch/decode rate of d instructions/cycle, and an issue rate of i instructions/cycle, it is necessary to update d+2i ready state entries each cycle.
This is a challenge for one write/cycle LUT RAM.
Rather than use clock doubling or replicated RAM banks with live value tables, the incremental scheduler divides the ready state up into four (or more) interleaved, disjoint banks:
(decoded, active) ready state for (even, odd) instructions.
Then the front end can write even and odd decoded ready state while the back end updates even and/or odd target instructions' active ready state.
Figure 6 shows the resulting a 16-entry scheduler bank design and implementation.
The blue decoded and active ready state LUT RAMs DRDYSS and ARDYSS are validated by orange/red FC-SO-RAMs DVS and AVS.
Each cycle the decoder writes instruction DC IID's decoded ready state DC DRDYS and its valid bit.
Also each cycle the bank's target ready event EVT ::={EVT IID; EVT RDYS} is processed via a read-modify-write of EVT IID's ARDYS with its DRDYS and EVT RDYS.
See Listing 2.
The instruction is ready when all four ARDYS bits are set.
All of this logic (cyan) requires just one slice; as an optimization READY's and-reduction is in carry-logic.