mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-08-17 21:29:20 +00:00
Corrected the descriptions of the llvm.writeport and llvm.writeio
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12867 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
e633352fd5
commit
96db6fcb2e
@ -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 <integer type> (<integer type>)* %llvm.readio (<integer type> <address>)
|
call <result> (<ty>*)* %llvm.readio (<ty> * <pointer>)
|
||||||
</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 (<integer type>, <integer type>)* %llvm.writeio (<integer type> <value>, <integer type> <address>)
|
call void (<ty1>, <ty2>*)* %llvm.writeio (<ty1> <value>, <ty2> * <pointer>)
|
||||||
</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>
|
||||||
|
Loading…
Reference in New Issue
Block a user