Magic-Mirror/llvm-capstone
1
0
Fork 0
mirror of https://github.com/capstone-engine/llvm-capstone.git synced 2025-01-21 07:42:52 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Corrected the descriptions of the llvm.writeport and llvm.writeio

Browse Source 
intrinsics.

Modified llvm.readio and llvm.writeio to use pointers to memory instead
of integers.  This should take care of problems such as different pointer
sizes, casting integers to pointers, weird architectural pointer types, etc.

Re-worded the description of llvm.readio and llvm.writeio so that it should
be more clear as to why they should be used over regular loads/stores for
I/O.

llvm-svn: 12867
This commit is contained in:
John Criswell 2004-04-12 16:33:19 +00:00
parent b753c8c9c5
commit 7a57647f97
1 changed files with 31 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
llvm/docs/LangRef.html
View File

@ -2077,13 +2077,13 @@ I/O port.
<h5>Arguments:</h5> <h5>Arguments:</h5>
<p> <p>
The first argument to this intrinsic indicates the hardware I/O address to The first argument is the value to write to the I/O port.
which data should be written. The address is in the hardware I/O address
namespace (as opposed to being a memory location for memory mapped I/O).
</p> </p>
<p> <p>
The second argument is the value to write to the I/O port. The second argument indicates the hardware I/O address to which data should be
written. The address is in the hardware I/O address namespace (as opposed to
being a memory location for memory mapped I/O).
</p> </p>
<h5>Semantics:</h5> <h5>Semantics:</h5>
@ -2107,7 +2107,7 @@ value written must be 8, 16, or 32 bits in length.
<h5>Syntax:</h5> <h5>Syntax:</h5>
<pre> <pre>
call &lt;integer type&gt; (&lt;integer type&gt;)* %llvm.readio (&lt;integer type&gt; &lt;address&gt;) call &lt;result&gt; (&lt;ty&gt;*)* %llvm.readio (&lt;ty&gt; * &lt;pointer&gt;)
</pre> </pre>
<h5>Overview:</h5> <h5>Overview:</h5>
@ -2120,24 +2120,28 @@ address.
<h5>Arguments:</h5> <h5>Arguments:</h5>
<p> <p>
The argument to this intrinsic indicates the memory address from which to read The argument to this intrinsic is a pointer indicating the memory address from
the data. which to read the data. The data must be a
<a href="#t_firstclass">first class</a> type.
</p> </p>
<h5>Semantics:</h5> <h5>Semantics:</h5>
<p> <p>
The '<tt>llvm.readio</tt>' intrinsic reads data from a memory mapped I/O The '<tt>llvm.readio</tt>' intrinsic reads data from a memory mapped I/O
location specified by <i>address</i> and returns the value. The address and location specified by <i>pointer</i> and returns the value. The argument must
return value must be integers, but the size allowed for each is dependent upon be a pointer, and the return value must be a
the platform upon which the program is code generated. <a href="#t_firstclass">first class</a> type. However, certain architectures
may not support I/O on all first class types. For example, 32 bit processors
may only support I/O on data types that are 32 bits or less.
</p> </p>
<p> <p>
This intrinsic ensures that the I/O data read occurs in instruction order in This intrinsic enforces an in-order memory model for llvm.readio and
relation to other I/O data reads and writes (as opposed to a normal load, where llvm.writeio calls on machines that use dynamic scheduling. Dynamically
hardware scheduling can re-arrange the actual memory accesses to occur out of scheduled processors may execute loads and stores out of order, re-ordering at
order). run time accesses to memory mapped I/O registers. Using these intrinsics
ensures that accesses to memory mapped I/O registers occur in program order.
</p> </p>
</div> </div>
@ -2151,7 +2155,7 @@ order).
<h5>Syntax:</h5> <h5>Syntax:</h5>
<pre> <pre>
call void (&lt;integer type&gt;, &lt;integer type&gt;)* %llvm.writeio (&lt;integer type&gt; &lt;value&gt;, &lt;integer type&gt; &lt;address&gt;) call void (&lt;ty1&gt;, &lt;ty2&gt;*)* %llvm.writeio (&lt;ty1&gt; &lt;value&gt;, &lt;ty2&gt; * &lt;pointer&gt;)
</pre> </pre>
<h5>Overview:</h5> <h5>Overview:</h5>
@ -2164,28 +2168,27 @@ mapped I/O address.
<h5>Arguments:</h5> <h5>Arguments:</h5>
<p> <p>
The first argument to this intrinsic indicates the memory address to which data The first argument is the value to write to the memory mapped I/O location.
should be written. The second argument is a pointer indicating the memory address to which the
</p> data should be written.
<p>
The second argument is the value to write to the memory mapped I/O location.
</p> </p>
<h5>Semantics:</h5> <h5>Semantics:</h5>
<p> <p>
The '<tt>llvm.writeio</tt>' intrinsic writes <i>value</i> to the memory mapped The '<tt>llvm.writeio</tt>' intrinsic writes <i>value</i> to the memory mapped
I/O address specified by <i>address</i>. The address and value must be I/O address specified by <i>pointer</i>. The value must be a
integers, but the size is dependent upon the platform upon which the program is <a href="#t_firstclass">first class</a> type. However, certain architectures
code generated. may not support I/O on all first class types. For example, 32 bit processors
may only support I/O on data types that are 32 bits or less.
</p> </p>
<p> <p>
This intrinsic ensures that the I/O data write occurs in instruction order in This intrinsic enforces an in-order memory model for llvm.readio and
relation to other I/O data reads and writes (as opposed to a normal store, llvm.writeio calls on machines that use dynamic scheduling. Dynamically
where hardware scheduling can re-arrange the actual memory accesses to occur scheduled processors may execute loads and stores out of order, re-ordering at
out of order). run time accesses to memory mapped I/O registers. Using these intrinsics
ensures that accesses to memory mapped I/O registers occur in program order.
</p> </p>
</div> </div>