[LLVMdev] LLVM and newlib progress

[John Criswell]

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.