国内のマルチクレットプロセッサはありますか？

この投稿では、ロシアのプロセッサを元のMulticletアーキテクチャで使用する取り組みについてお話したいと思います。 Embox RTOSをこのプラットフォームに移植することに興味があります。これにより、既にお話ししたSIP電話など、かなり多数のアプリケーションを使用できるようになります。



転送プロセス中に発生した問題と、これらの問題をどのように修正したかについてです。 おそらく、これはこのプロセッサを使用する予定がある人だけでなく、何らかの理由でc99およびgcc標準からc89標準に変更する必要がある人やgccコンパイラと互換性のない人にとっても興味深いでしょう。 また、結論として、このプラットフォームとのやり取りから個人的な感情を追加できるようにします。

ロシアの現実について

私たちが購入したキットは最高級で、かなりの費用がかかります。 もちろん、エルブラスほど高価ではありませんが、同じラズベリーとは比較できません。 しかし、それを忘れた場合、送信されたキットはかなりまともに見えました。 私の意見では、価格はほとんど手作業であるため、限られた当事者に起因するはずです。





私たちが遭遇した別の特徴は、配達時間でした。 キットは2月に戻ってくる予定で、7月に届きました。 しかし、私たちの側からのいくつかのキック、マルチクレットからの保証と保証書-そして、ついに、待望のパッケージが到着しました。

移植を始める

国内プロセッサの存在を確信したとき、RTOSをこのプラットフォームに移植するために、このデバッグキットを購入したものに進みました。 すでに述べたように、プロジェクトによるマルチレットのサポートにより、当然、マルチタスク、ネットワークスタック、ファイルシステム、ブラックジャックを備えた幅広いクラスのアプリケーションを自動的に使用できるようになります。



経験豊富な人として、かつて個人的に元のプロセッサアーキテクチャに直面したことがありましたが、私はすぐに技術的な質問に答えることができる人との接触を確立しようとしました。 残念ながら、最初の段階では、私はこの問題で特に成功しませんでした。 コンパイラーについて質問するために、コンパイラーをダウンロードできるページへのリンクと、このサイトにあるプロセッサーの操作方法の説明を受け取りました。



非常に励みになる状況ではありませんが、少なくともコンパイラーはありました！ c89ですが、彼はソースコードと提供された例をコンパイルしました。 楽観主義は、FreeRTOSをこのアーキテクチャに移植することに関する記事をすでに見ていたという事実にも触発されました。 そのため、松葉杖では動き回ることができなかった困難な課題に突き当たるまで移動することにしました。

コンパイラの技術詳細

MultkletのコンパイラCはlccに基づいており、残念ながら、コマンドラインインターフェイスを含むすべての点で主流のgcc / llvm / iccと互換性がありません。 少なくとも1つのファイルをコンパイルしようとした最初の試みで、サポートされていないフラグがたくさん見つかりました。 最も厄介なのは、-include xhコンパイラオプションがないことで、このオプションには、コンパイル済みファイルの最初の行が#include <xh>であるかのように、前処理用のxhファイルが含まれます。



原則として、これは標準的な手法ではありませんが、この方法では、たとえば、生成された構成ファイル（および多くのファイルがあります）を転送することは非常に便利です。



次の違いは、コンパイラを一般に提供することでした。 実際のところ、lccは単なるコンパイラであり、gccはコンパイラ用のユーティリティ（ld、as、cc、..）のコレクションに過ぎません。 Gcc自体は、これらすべてのユーティリティの一種のラッパーとして機能します。より簡単には、コンパイラドライバーです。 つまり、gccを介してアセンブラーまたはリンカーを呼び出すのは正しいことです。gccは、すべてのパラメーターを、正しくインストールされた環境の対応するユーティリティに転送します。 一般に、LDとASを構築するために別々の変数を導入し、ホストマシンからARユーティリティを取得する必要がありました。 以前に-ld、-as、および-arをクロスツールの名前（mips-elfなど）に割り当てることが可能であり、それらは通常、対応するフラグを使用してSS経由で呼び出された場合、この場合、ユーティリティを明示的に呼び出す必要がありました。



もちろん、リンカーも驚きを示しました。



これらの最初のものは、中間オブジェクトファイルを作成するための-rフラグ（--relocatable）の欠如でした。 メタ情報を生成するときにこれらのオブジェクトを使用します。たとえば、システムの各モジュールの整合性をチェックするチェックサムを計算します。 まあ、一般的に、これは動的モジュールとライブラリを使用することになると非常に便利です。



もっともっと。 静的ライブラリの操作は貧弱です。 ライブラリは-lオプションのみを使用して転送できるだけでなく、フルパスを含めることもできません。 このため、同じ名前の異なるライブラリをリンクすることは基本的に不可能です。 さらに、-start-group /-end-groupのサポートの欠如は不快です。



また、コンパイラにすでに関連している、かなり興味深い不快な事実を追加することもできます。その中で-lオプションがオーバーライドされます。 lccでは、-lccdirの同義語です。

ソース変更

次に、ソース自体に進みましょう。 それらがc99またはgnucであり、コンパイラがc89であることを思い出させてください。 問題が発生したはずであることは明らかです。 最初の問題は、コンパイラーではなく、プリプロセッサーでも発生しました。 このコンパイラは、 mcppプリプロセッサを使用します。 一般に、可変数の引数を持つマクロはgccとは異なる方法で処理されることがすぐに判明しました。「テール」は空にできません。つまり、 1つの必須引数を持つマクロは、2つ未満の引数で呼び出すことはできません。 たとえば、assertなどのマクロを変更する必要がありました。 以前は、確認のための式だけでなく、エラーメッセージ行も受け取ることができました。これは非常に便利な場合があります。 原則として、これはマクロの標準的な動作ではないため、別のマクロassertf（）を作成し、発生したソースをコンパイルしませんでした。



コンパイラに戻ります。 インラインキーワードはc90で登場しましたが、マルチレットコンパイラではサポートされていません。 マクロの代替として静的インライン関数を広範囲に使用します。 出力はcompiler.hファイルの導入で、ifdefがインラインサポートの欠如を決定します。この場合、インラインは空のマクロ（#define inline / * nothing * /）として宣言されます。



コンパイラは、 指定された初期化子をサポートしません。 この問題はプリプロセッサの助けを借りて解決することはできません。また、古い標準をサポートするためにソースコードをダウングレードしたくはありませんでした。 c99-to-c89ツールが助けになり、その場でc99コードがc89に変わります。



また、コンパイラはgnucの拡張であるtypeofキーワードをサポートしていません。 たとえば、マクロminおよびmaxを記述するために使用します。

/** @return the larger of @aa and @ab */ #define max(a, b) \ ({ \ typeof(a) __max_a = (a); \ typeof(b) __max_b = (b); \ __max_a > __max_b ? __max_a : __max_b; \ }) /** @return the smaller of @aa and @ab */ #define min(a, b) \ ({ \ typeof(a) __min_a = (a); \ typeof(b) __min_b = (b); \ __min_a < __min_b ? __min_a : __min_b; \ })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、整数変数の場合、次のように簡単に記述できます。

 #define max(a, b) ((a) > (b) ? (a) : (b)) #define min(a, b) ((a) < (b) ? (a) : (b))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、ヘッダーファイルのインクルードを単に破棄してそのように定義することにより、いくつかの場所で行いました。



最大の問題は属性でした。 コンパイラーは、アライメントの設定、構造のパッキング、特定のセクションへのデータまたはコードの配置をサポートしていません。 これらのことなしに行うことは非常に困難です。 たとえば、セクションでの作業を非常に積極的に使用しています。システムのロードでさえ、特定のセクションにポインターを配置するという原則に基づいています。 残念ながら、この問題を解決できなかったため、現在の段階では、システムの起動に関する行をシリアルポートに出力するだけに制限することにしました。



実際、マルチクレットアーキテクチャのサポートを開始したとき、すぐにいくつかの質問がありました。 今回、私はカンニングをすることにし、Habréで何かを書いたマルチレットスタッフと連絡を取りました。 本当にありがとうございます。 彼はすぐに私の質問に答えてくれ、彼のおかげで、マルチクレットアーキテクチャ用のstdarg.hを入手しました。 ブートコードはサンプルからも送信されましたが、原則として、マルチレットサイトからダウンロードすることもできます。 誤解もありましたが、それについては広めたくありません。 最終的に、彼らはマルチクレットフォーラムで質問する方が良いと判断しました。

ボードへの画像の塗りつぶし

コンパイル後、キットを解凍しました。 私が言ったように、彼は非常に立派に見えました。







しかし、jtagを接続するときに、ボードのドキュメントにこれを行う方法に関する情報が含まれていないことが判明しました。 ファームウェア用のコマンドはありましたが、jtagコネクタに適切にプラグインする方法に関する情報はありませんでした。 同時に、彼が完璧にフィットする2つのコネクタがありました。 経験的に、次のようにこれを行うのが正しいことがわかりました。





実際、マルチレットに質問をしましたが、コネクタの写真を追加してマニュアルをすでに更新しているようです。

画像打ち上げ

切望されたラインへの最後の障害は、リンカーのバグでした。これらはすでに提出されたものから修正されています。



一番下の行は、完成した例は機能しましたが、実際には、Emboxイメージは同じコードで機能していませんでした。 私はすぐに、メモリ内のプログラムオブジェクトの不適切な配置について疑いを抱きました。 私たちのイメージは例よりもかなり太かったため、最初はスタックに罪を犯し、256 kBのメモリの終わりを指すスタックは何かを上書きするだけだと考えました。そのような先例がありました。 readelfを使用して、すべてが寸法で問題ないことが判明し、開始アドレスで罪を犯し始めました。 つまり、プログラムが正しくリンクされていることを確認したかったのです。 開発キットには逆アセンブラが含まれていないことが判明しました。 その結果、リンカがラベルのアドレスを表示した後、仮定が確認されました。 Emboxとサンプルの違いは、サンプルの最初のオブジェクトファイルが常にcrt0.oであったことです。



アセンブラーでの.sectionディレクティブのサポートとリンカーでの対応するサポートを追加するように依頼し、「ドキュメントを読む」フォーラムで応答を受け取りました。 私は、これが機能しないことを示すソースコードの例を読んで確認し、例を挙げました。 一般に、同じkrufterの助けを借りて、問題は解決されました。



そして、私はついに待望のラインを見ました：







残念ながら、コンパイラにいくつかの機能を追加せずにさらに前進させることは非常に困難であり、次に何をすべきかを考えることにしました。コンパイラを自分で切るか、コンパイラがマルチクレットを完了するまで無期限に待つかです。 後者は、c99互換の最適化コンパイラを作成することを決定したため、あまり有望ではないようです。 また、gccまたはllvmをベースとして使用するのではなく、マシンの組織が登録されていないという事実を引用して、独自にカットします。

個人的な感情

警告されたように、私は私の個人的な感情を表現させてください。 最後に、マルチクレット開発者自身が記事でこれを求めました。



私はハードウェアコンポーネントについては詳しく述べません。barsmonsterは彼の記事でこれについてかなりきちんと書いています 。 システムプログラマーの観点から、鐘楼からの問題を見てみるとよいでしょう。



したがって、プロセッサは物理的に存在します。 もちろん、これは喜ばしいことですが、ロシアの電子産業がいつプロセッサを必要としないことを理解するかは明確ではありません。 インテルはソフトウェアに多額の投資を行っており、これらの投資はプロセッサーの開発と直接生産への投資を上回っています。



他のすべてのメーカーも、アプリケーションを開発して、すでに作成されたソフトウェアを実行できない場合、パフォーマンスプレートが意味をなさないことを理解しています。 これまで、「 Multiclet IDEのテスト方法 」などの記事は奇妙に見えます。 つまり、本当にアセンブラーコードを記述することになっていますか？ いいえ、もちろん、現代のプログラマーが組み込みシステムに必要なのは、プログラムをボードに直接アップロードできるIDEだけであることを理解しています。 私はこの記事の結論に同意する用意ができています。

したがって、実装が単純であるにもかかわらず、提案された機能は、大規模で複雑なプロジェクトの完全なデバッグにも十分です。 ツールパッケージの更新された機能により、直感的で便利なインターフェイスを提供することにより、開発速度を大幅に向上させることができます。

しかし、STMは言うまでもなく、少なくともArduinoの機能を繰り返すのにどのように役立つのかわかりません。



または、「 国内のプロセッサで作業するためにすでに訓練された専門家があなたの企業に来る 」という計算ですか？ 国内ではこれで終わりです！ いいえ、本気ですか？ 現在、専門家は特定のプロセッサーで作業するように教えられていますか？



一般的に、私の個人的な印象は2つあります。 一方で、新しいことをしようとしている人々は勇気づけられ、他方では、このアプローチは大学生に非常に目に見えます。 彼らはプロセッサを作り、テストで行われた作業について報告し、「私たちは最高であり、私たちはすべて自分でやる！」 誰がそれを必要とし、誰がこの製品を望み、使用できますか？



コミュニティへの質問で終わりたいと思います。

実際のアプリケーションがまだ作成されていない場合、国内のMulticletプロセッサがあると思いますか？



PS感情的な結論はもっぱら私の個人的な感情です。

PPSこの記事で説明されているコードは 、リポジトリのブランチにあります。 もちろん、同様のボードでダウンロードしてテストできます。