CPUの機能の発揮
C言語は、CPUの性能向上を阻害せず、CPUの能力を最大限発揮することができるようにするための言語である。
機械語、アセンブラでも、CPUの能力を発揮することは実現可能である。
関数言語
まとまった処理などを、機械語、アセンブラ、またはそれらをマクロとして定義したライブラリよりも、
関数として扱うことができるようにしたものがC言語である。
関数で値を戻すこと以外の機能を副作用として位置付け、プリプロセッサ処理の機能、関数の機能の実現方法で、副作用が生じる可能性のある設計について、随所に記述している。
厳密な仕様化
定義しないことを仕様として決めている。
そこで、CPUの性能発揮を阻害しないようにするための機能が、
CPUの性能に影響を与えるような仕様は定義しない「未定義」、
CPUの性能発揮を選択可能にした仕様「未規定」、
CPUの性能発揮を、現在の技術ではなく、将来の技術で優位に立つ可能性を残した「処理系定義」
というすばらしい仕様定義がある。
これらは、仕様の欠陥ではなく、CPUが8bit, 16bit, 32bitと進化する過程において、
CPUの設計を縛らないための仕様として優れている。
公開による標準化
C言語規格は当初ANSIで規定し、その後ISO/IECの国際規格になっている。
C言語を規定しているISO/IEC JTC1 SC22 WG14では、さまざまな文書を公開して審議をすすめている。
http://www.open-std.org/jtc1/sc22/wg14/www/standards
最新の案はN2310である。
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
近年では、CPUの主流が32bitで２０年以上止まり、64bitで上げ止まりそうな気配である。
FPGA、GPUなどの従来のCPUとは異なる構造の進展と、量子コンピュータの実現により、新たなハードウェア依存の言語の可能性は増えている。)
現在の未定義、未規定、処理系定義は、32bit仕様、64bit仕様を定義することには価値があるかもしれない。
ちょうど、LinuxがそれぞれのCPUごとの仕様を定義したように。
C言語の優れたところを継承した、FPGA, GPU, 量子コンピュータのハードウェア依存を効率的に記述できる言語仕様は、
「未定義」「未規定」「処理系定義」を、しっかりと定義することである。
これらは欠陥ではない。
過去に、Safer Cという書籍で、未定義、未規定、処理系定義の差による課題の提起があった。
また、実際のCPU、処理系の違いを意識せずにプログラムがかけるようにするためのMISRA Cなどの言語部分集合(subset)定義の提案おあった。
実際のCPU、処理系の現状に見合った、未定義、未規定、処理系定義の見直しは、既存のプログラムの存在価値の評価を経ずにすることは困難かもしれない。
文書履歴(document history)
ver. 0.01 初稿 20190130 朝
ver. 0.02 Linux等追記 20190130 午前
| page | paragraph | section | text |
|---|---|---|---|
| 11 | 5.1.2.3 Program execution | A volatile access to an object, modifying a file, or calling a function that does any of those operations are all side effects,12) which are changes in the state of the execution environment. Evaluation of an expression in general includes both value computations and initiation of side effects. 12)The IEC 60559 standard for binary floating-point arithmetic requires certain user-accessible status flags and control modes. Floating-point operations implicitly set the status flags; modes affect result values of floating-point operations. Implementations that support such floating-point state are required to regard changes to it as side effects — see Annex F for details. The floating-point environment library provides a programming facility for indicating when these side effects matter, freeing the implementations in other cases. | |
| 12 | … | The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect | |
| associated with A is sequenced before every value computation and side effect associated with B. (A summary of the sequence points is given in Annex C.) | |||
| 12 | … | In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile ::::::: through::::::: volatile:::::: access:: to::: an:object). | |
| 14 | NOTE 2 For example, a call that acquires a mutex will perform an acquire operation on the locations composing the mutex.Correspondingly, a call that releases the same mutex will perform a release operation on those same locations. Informally, performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform an acquire or consume operation on A. Relaxed atomic operations are not included as synchronization operations although, like synchronization operations, they cannot contribute to data races. | ||
| 15 | A release sequence headed by a release operation A on an atomic object M is a maximal contiguous sub-sequence of side effects in the modification order of M, where the first operation is A and every subsequent operation either is performed by the same thread that performed the release or is an atomic read-modify-write operation. | ||
| 15 | Certain library calls synchronize with other library calls performed by another thread. In particular, an atomic operation A that performs a release operation on an objectM synchronizes with an atomic operation B that performs an acquire operation on M and reads a value written by any side effect in the release sequence headed by A. | ||
| 15 | An evaluation A is dependency-ordered before16) an evaluation B if: — A performs a release operation on an atomic object M, and, in another thread, B performs a consume operation on M and reads a value written by any side effect in the release sequence headed by A, or | ||
| — for some evaluation X, A is dependency-ordered before X and X carries a dependency to B. | |||
| 16 | 20 | A visible side effect A on an object M with respect to a value computation B of M satisfies the conditions: — A happens before B, and — there is no other side effect X to M such that A happens before X and X happens before B. The value of a non-atomic scalar object M, as determined by evaluation B, shall be the value stored by the visible side effect A. | |
| 21 | NOTE 9 If there is ambiguity about which side effect to a non-atomic object is visible, then there is a data race and the behavior is undefined. | ||
| 23 | The value of an atomic object M, as determined by evaluation B, shall be the value stored by some side effect A that modifies M, where B does not happen before A. | ||
| 24 | NOTE 11 The set of side effects from which a given evaluation might take its value is also restricted by the rest of the rules described here, and in particular, by the coherence requirements below. | ||
| 27 | If a value computation A of an atomic object M happens before a value computation B of M, and A takes its value from a side effect X on M, then the value computed by B shall either be the value stored by X or the value stored by a side effect Y on M, where Y follows X in the modification | ||
| order of M. | |||
| 29 | If a value computation A of an atomic object M happens before an operation B on M, then A shall | ||
| take its value from a side effect X on M, where X precedes B in the modification order of M. | |||
| 31 | If a side effect X on an atomic object M happens before a value computation B of M, then the | ||
| evaluation B shall take its value from X or from a side effect Y that follows X in the modification | |||
| order of M. | |||
| 34 | 5 | Certain object representations need not represent a value of the object type. If the stored value of an | |
| object has such a representation and is read by an lvalue expression that does not have character | |||
| type, the behavior is undefined. If such a representation is produced by a side effect that modifies | |||
| all or any part of the object by an lvalue expression that does not have character type, the behavior | |||
| is undefined.51) Such a representation is called a trap representation. | |||
| 40 | 1 | 6.3.2.2 void | The (nonexistent) value of a void expression (an expression that has type void) shall not be used in any |
| way, and implicit or explicit conversions (except to void) shall not be applied to such an expression. | |||
| If an expression of any other type is evaluated as a void expression, its value or designator is | |||
| discarded. (A void expression is evaluated for its side effects.) | |||
| 52 | 2 | 6.4.6 Punctuators | A punctuator is a symbol that has independent syntactic and semantic significance. Depending on |
| context, it may specify an operation to be performed (which in turn may yield a value or a function | |||
| designator, produce a side effect, or some combination thereof) in which case it is known as an | |||
| operator (other forms of operator also exist in some contexts). An operand is an entity on which an | |||
| operator acts. | |||
| 55 | 2 | 6.5 Expressions | If a side effect on a scalar object is unsequenced relative to either a different side effect on the |
| same scalar object or a value computation using the value of the same scalar object, the behavior | |||
| is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the | |||
| behavior is undefined if such an unsequenced side effect occurs in any of the orderings.87) | |||
| 3 | The grouping of operators and operands is indicated by the syntax.88) Except as specified later, side | ||
| effects and value computations of subexpressions are unsequenced.89) | |||
| 12 | EXAMPLE In the function call | ||
| (*pf[f1()]) (f2(), f3() + f4()) | |||
| the functions f1, f2, f3, and f4 can be called in any order. All side effects have to be completed before the function pointed | |||
| to by pf[f1()] is called. | |||
| 61 | 3 | 6.5.2.4 Postfix increment and decrement operators | operand object is incremented (that is, the value 1 of the appropriate type is added to it). See the |
| discussions of additive operators and compound assignment for information on constraints, types, | |||
| and conversions and the effects of operations on pointers. The value computation of the result is | |||
| sequenced before the side effect of updating the stored value of the operand. With respect to an | |||
| indeterminately-sequenced function call, the operation of postfix++ is a single evaluation. Postfix | |||
| ++ on an object with atomic type is a read-modify-write operation with memory_order_seq_cst | |||
| memory order semantics.102) | |||
| 63 | 3 | 6.5.3.1 Prefix increment and decrement operators | The value of the operand of the prefix++ operator is incremented. The result is the new value of the |
| operand after incrementation. The expression++E is equivalent to (E+=1). See the discussions of | |||
| additive operators and compound assignment for information on constraints, types, side effects, | |||
| and conversions and the effects of operations on pointers. | |||
| 73 | 3 | 6.5.16 Assignment operators | An assignment operator stores a value in the object designated by the left operand. An assignment |
| expression has the value of the left operand after the assignment,115) but is not an lvalue. The type of | |||
| an assignment expression is the type the left operand would have after lvalue conversion. The side | |||
| effect of updating the stored value of the left operand is sequenced after the value computations of | |||
| the left and right operands. The evaluations of the operands are unsequenced. |
Reference
Ethernet 記事一覧 Ethernet(0)
https://qiita.com/kaizen_nagoya/items/88d35e99f74aefc98794
Wireshark 一覧 wireshark(0)、Ethernet(48)
https://qiita.com/kaizen_nagoya/items/fbed841f61875c4731d0
線網（Wi-Fi）空中線(antenna)(0) 記事一覧(118/300目標)
https://qiita.com/kaizen_nagoya/items/5e5464ac2b24bd4cd001
一覧の一覧( The directory of directories of mine.) Qiita(100)
https://qiita.com/kaizen_nagoya/items/7eb0e006543886138f39
プログラマが知っていると良い「公序良俗」
https://qiita.com/kaizen_nagoya/items/9fe7c0dfac2fbd77a945
小川清最終講義、小川清最終講義（再）計画, Ethernet(100) 英語(100) 安全(100)
https://qiita.com/kaizen_nagoya/items/e2df642e3951e35e6a53
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20230526
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.