Pertti Kellomäki wrote:> John Criswell kirjoitti:
>
>> So, let me see if I understand this right:
>>
>> First, it sounds like you're programming on the bare processor, so
your
>> I/O instructions are either special processor instructions or volatile
>> loads/stores to special memory locations.
>>
>
> Yes. In more detail, instruction words directly control the
> data transports inside the processor, and I/O is handled
> by transporting data into a special function unit.
>
So a particular instruction actually specifies where in the
miroarchitecture a particular piece of data should go. Directing it to
a specific functional unit makes it do I/O. Right?
>
>> In that case, you would not
>> use a "system call" intrinsic;
>>
>
> Correct.
>
>
>> you would use an ioread/iowrite intrinsic
>> (these are similar to load/store and are briefly documented in the
>> LLVA-OS paper).
>>
>
> Which I should probably read, it seems.
>
The LLVA-OS paper contains descriptions of intrinsics that we would add
to LLVM to support an operating system. In our implementation, we wrote
them all as external library functions. While I suspect that most of
our paper is not relevant in solving the problems you're working on,
some bits of information (like ioread/iowrite and llva_syscall) may be
of interest to you.
If you read about something in the LLVA-OS paper and have questions on
it, please feel free to ask. The paper is rather light on details
because we had an incredibly short page limit.
So, llva_ioread() and llva_iowrite() read and write values to I/O
locations. The locations can be anything: I/O port numbers (e.g. x86),
the memory address of a memory mapped device register, or the identifier
of a functional unit. The important part is that llva_ioread() and
llva_iowrite() are code generated into the correct assembly code
sequences for I/O and, at the LLVM level, they are considered volatile,
so they are not moved around or eliminated by LLVM optimization passes.
> If you're doing memory mapped I/O, you could probably
>
>> use LLVM volatile load/store instructions and not have to add any
>> intrinsics.
>>
>
> We could do memory mapped I/O, but I don't thing it is being
> considered.
>
>
>> Second, you could implement these "intrinsics" as either
external
>> functions or as LLVM intrinsic functions specially handled by the code
>> generator. I believe you're saying that the encoding of the I/O
>> instructions change.
>>
>
> It is up to the processor designer to decide where the
> I/O units are located in the processor, so yes.
>
If you end up designing a new intrinsic for handling I/O due to any
limitations in ioread/iowrite, please let us know. We wanted our LLVA
intrinsics to be adaptable to novel hardware designs; we'd appreciate
any feedback we can get.>
>> If that is the case, then you are right: adding an
>> intrinsic and having the LLVM code generator generate the right
>> instructions would probably be easiest.
>>
>> Do I understand things correctly?
>>
>
> It would seem so. Thanks for your insights!
>
Your welcome.
-- John T.