[movitz-devel] Re: A 32-bit read/write with %io-port-read/write-succession

[Frode Vatvedt Fjeld]

Elliott A Johnson <human at csufresno.edu> writes:

> I had a quick question about this function and its macro helper.  If I'm
> understanding correctly, %io-port-write-succession would shift a 32-bit
> number by a 2-bit offset, write 30bits, then write the unwritten
> 2-bits?

This is, if my memory and code-reading ability isn't totally warped,
incorrect. These operators deal purely with "raw" (untyped) data
quantities, i.e. 8, 16, or 32 bits, both in terms of main memory and
I/O-ports. So the object parameter is not type-checked in any way, and
you (the caller) had better be knowledgeable about its memory layout
etc.

> Is "io-port-w/r-succession" the preferable way of doing a 32-bit
> transfer to registers,

It should be the preferred way of transporting a block of data (such
as a network packet or disk block), most likely in the form of a lisp
array, to an I/O-port. An equivalent but less efficient alternative
would be to use io-port and memref (or aref for typed access to the
object) inside a loop. If you mean literally _a_ (one) transfer to an
I/O-port, just use the io-port operator.

This is how e.g. the read-succession operator should work (i.e. the
compiler-macro is just a hand-written assembly version of this code):

(defun %io-port-read-succession (port object offset start end byte-size)
  (cond
    ((eq :32-bit byte-size)
     (do ((i start (1+ i)))
         ((>= i end) object)
       (setf (memref object offset i :unsigned-byte32)
          (io-port port :unsigned-byte32))))
     ...))

The term "succession" btw I invented to mean a sequence/block of
untyped memory. Suggestions for better names are welcome. Perhaps
"memblock" or "memory-block" would be more easily understood?

> ps- is this sort of 2 stage writing to registers ok?  I'd think most
> synchronous read or writes would want to be performed in a single
> cycle?

Absolutely, such a 2-stage writing or reading would be unacceptable in
general, both for performance and functional reasons.

-- 
Frode Vatvedt Fjeld