Memory Mapped IO

[David Smith]

When dealing with memory mapped IO, is there a neat way to axiomatically say "there is something at address 0x12345678?

At the moment I'm using a C macro that just returns the address, and then have an at-view in the ATS type signature, though I'd prefer to somehow treat that as global, if only so I don't have to "pseudo-free" the stuff every time I use it.

Thanks in advance.

[Troy Jacobs]

I'd suggest using an external function/value with dependent types that tell ATS the "sort" of the pointer is "agz" (arguements greater than zero.)  I'll try to put together an example.

--
You received this message because you are subscribed to the Google Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/baa3dbd2-410f-44d5-be2e-2bbd6e7efcf5n%40googlegroups.com.

[d4v3y_5c0n3s]

Sorry for the delay on this response.

    Basically, as for having ATS thing that a pointer is valid, you'd create an "extern" function like this:

extern fn name_here () : [l:addr] (typename @ l | ptr l)//  where this function points to something in C

    As for not having to "psuedo-free" the return value every time you are done with it, there are several things that can be done.  First, in certain instances you can use templates to make things easier to manage, but explaining exactly what I mean is kind of difficult to articulate over Google Groups.  You'll have to take my word for it, and you'll likely understand when you play with templates more.

    Second, this "psuedo-free" issue is a natural consequence of using linear types, these restrictions are designed to make resources less likely to be mismanaged.  Rather than trying to avoid this pattern completely, I'd suggest formalizing this relationship with ATS' type system.  I'd take a look at the "Reader and Writer" pattern here to get an idea of what I'm suggesting.  Basically, you'd have a view for the memory IO that acts as a "key" of sorts.  Whenever you call the function I suggested above, this view would be consumed, preventing anyone else from calling that function.  When you are done, you'd call another function that consumes this pointer to the memory IO and gives you back the "key" view.  Now, you can call the first function again since you've finished touching that memory.  The benefit of doing this is that wouldn't have to worry about things like calling the function at the same time in concurrent code.  It also looks better, so there's that.

[Owen Avery]

While I'm just trying to figure out the language at this point, you could try something involving praxi.