fprintf support in CATS files effects compilation for embedded target

[Mike Jones]

I'm adding some I2C support to arduino-ats and decided to look under the hood to see why the arduino prelude uses modified versions of CATS files, and see if it would be possible to use the standard prelude for ATS2. It looks like the primary reason for copying CATS files, is to remove code related to stdio and printing.

This leads to some questions about how enable the embedded developers at the end of the discussion of things I tried to get around the problem.

Some discussion of things I tried...

As an experiment, I forced the inclusion of the avr version of stdio.h and it creates errors because stderr/out/in are macros, and the avr toolchain seems to have a problem with nested macros. As an experiment, I changed the stdio.h to have these definitions:

extern struct __file *stdin; /* Standard input stream.  */

extern struct __file *stdout; /* Standard output stream.  */

extern struct __file *stderr; /* Standard error output stream.  */

Which removes the error and leaves the following error:

/opt/ATS/ATS2-Postiats-0.2.2/prelude/CATS/integer.cats:980:55: error: expected ‘)’ before ‘(’ token

 #define atspre_print_int(x) atspre_fprint_int(stdout, (x))

                                                                                  ^

In case of spacing in the text, the ^ is at (x)

The code called from this generated code in the .c file:

ATSextern()

atsvoid_t0ype

atspre_print_int(atstkind_t0ype(atstype_int) arg0)

{

/* tmpvardeclst(beg) */

// ATStmpdec_void(tmpret80) ;

ATStmpdec(tmpref81[32], atstkind_t0ype(atstype_byte)) ;

I assume the compiler is bumping into a similar nested macro problem.

Back to the real question. 

Stdio is not something always available when you are dealing with bare iron or RTOS based platforms, and often it is senseless. So I am asking how might this be addressed? My thoughts are that faking out ATS with functions that are not needed is a poor approach. I think it would make more sense to have a #define to either turn off everything related to stdio, or allow for user definitions, or both. Another approach might be to factor out the code into one file/interface so that an application can simply not include it.

In general, I think coupling any core libraries to IO or an OS API will limit the user base, if those libraries are essential to quick success.

Thoughts?

Mike

[Hongwei Xi]

There should really be no problems with using avr/stdio.h.

I think the reason for your trouble is that functions like print_int and print_string

are not defined based on avr/stdio.h.

>>extern struct __file *stdin;        /* Standard input stream.  */
>>extern struct __file *stdout;        /* Standard output stream.  */
>>extern struct __file *stderr;        /* Standard error output stream.  */

This is problematic. Do not make use of 'stdin' if it is not available. If you post some

code, I will prbably suggest something more concrete.

--
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 post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/66e072f9-4651-427a-b2ce-4db96b2103ea%40googlegroups.com.

[Mike Jones]

Let me get a bit more specific about the error and see if you can help make it work with the avr stdio.h

I changed the avr_prelude like this, so that stdio.h is included before the ats prelude.

#include "stdio.h"

#include "prelude/CATS/integer.cats"

#include "avr_prelude/CATS/pointer.cats"

...

Basically, just try one file from the ats prelude. In the errors below, I have used bold type where the caret points to the error.

The default avr stdio.h has:

The default stdio.h has:

struct __file {

char *buf; /* buffer pointer */

unsigned char unget; /* ungetc() buffer */

uint8_t flags;

        ...

extern struct __file *__iob[];

#define stdin (__iob[0])

#define stdout (__iob[1])

#define stderr (__iob[2])

Here is an example error from the compile:

In file included from ../../avr_prelude/kernel_prelude.cats:7:0,

                 from hardware_serial_dats.c:57:

hardware_serial_dats.c: At top level:

/opt/ATS/ATS2-Postiats-0.2.2/prelude/CATS/integer.cats:980:47: error: expected declaration specifiers or ‘...’ before ‘(’ token

 #define atspre_print_int(x) atspre_fprint_int(stdout, (x))

hardware_serial_dats.c:2264:1: note: in expansion of macro ‘atspre_print_int’

 atspre_print_int(atstkind_t0ype(atstype_int) arg0)

 ^

Now I change the definition to the following to remove the stdxx macros:

>>extern struct __file *stdin;        /* Standard input stream.  */
>>extern struct __file *stdout;        /* Standard output stream.  */
>>extern struct __file *stderr;        /* Standard error output stream.  */

The error becomes:

In file included from /home/mike/arduino-ats/avr_prelude/kernel_prelude.cats:8:0,

                 from hardware_serial_dats.c:57:

hardware_serial_dats.c: At top level:

/opt/ATS/ATS2-Postiats-0.2.2/prelude/CATS/integer.cats:980:55: error: expected ‘)’ before ‘(’ token

 #define atspre_print_int(x) atspre_fprint_int(stdout, (x))

hardware_serial_dats.c:2264:1: note: in expansion of macro ‘atspre_print_int’

 atspre_print_int(atstkind_t0ype(atstype_int) arg0)

 ^

My interpretation is the preprocessor can't expand the nested macro, in both cases.

I was mainly surprised at the error when using the modified stdio.h

 

[gmhwxi]

To be honest, I am not yet clear as to what problem needs to be solved here.

I see that you have the following line in your code:

>>#include "prelude/CATS/integer.cats"

Is it that you want to modify prelude/CATS/integer.cats so that it could work
with avr-cc?

[Mike Jones]

There are two parts:

A) Undertand the compilation error and see if there is a work around, with the goal of removing the copied/modifed versions of CATS files in arduino-ats, because it will be hard to maintain a copy

B) See if there is reason for prelude/CATS/integer.cats and other cats files to be modified in some way to remove stdio for those targets that can't support it. By remove, I don't mean copy/modify, but to modify the files for an ATS release.

I am basically saying that coupling the CATS files to IO too tightly makes ATS difficult for embedded users and I am searching for a solution, because for me ATS's highest value is for embedded platforms.

[gmhwxi]

To me, using a different set of CATS files for arduino-ats is a reasonable
design for otherwise we may have to introduce a lot of #if-guards, which could
be confusing (and likely harder to maintain).

Actually, it will be really good if someone can write a script for automatically generating
CATS files targeting different platforms.

[Mike Jones]

My concern is that different CATS files for the embedded world means 20+ of them to cover RTOS, SDKs, ARM/i386, etc.

A generator would be nice I suppose, but that can get complicated. I think that just moves the complexity, but does not solve it. What happens when the script generator creates code that does not compile and everyone blames ATS?

I think it would be fine to have something like how memory is handled. You can have MALLOC, GC, or user.

It would be a fair question to ask what about other couplings. From what I have seen so far, there is not much coupling except stdio. Everything else seems to be pure C.

[gmhwxi]

I have just moved various fprint-functions out of
integer.cats, bool.cats, char.cats, pointer.cats, string.cats. etc.
Now you should be able use these CATS files in arduino-ats directly.

[William Blair]

If you're interested, I worked on an ATS library for creating I2C applications on AVRs a while back. It was mostly adapted from a couple of Atmel application notes written in C. The code is in ATS1, but I would like to revise it to possibly use session types for describing the protocols devices implement on top of I2C.

overview:

http://blogs.bu.edu/wdblair/2012/11/01/transactions-on-a-two-wire-bus/

interface:

https://github.com/wdblair/avr-libats/blob/master/SATS/twi.sats

[Mike Jones]

William,

I'll have a look. Right now, I have the twi files from arduino 1.6.5 inside the arduino-ats tree, and and a modified version of the Linduino LT_I2C. My application is running on the Linduino code, but I am going to try to move to the twi layer. I'll look at what you have before I move the code.

It will take a while, because I want to try to remove the CATS files first, and there is a code update waiting for me.

The ideal would be to remove the copied code from arduino-ats as well and just layer over a standard arduino tree, but that will more work. Some of the arduino code required is C++, and the current arduino-ats code is a mix of arduino c and ats recoded arduino C++.

When I get a little farther I need to work with the owner of the code to coordinate inspections and merges, etc. However, I can provide the twi files and an example if anyone wants to use it.

[Mike Jones]

Dumping the CATS files into arduino-ats gets into trouble with missing files like ats_types.h. So perhaps its better to build it, but the git repo does not have the proper configure and makefiles. I tried the ones from the tarball, which is not quite recent enough to have the refactored CATS files, but I get failures straight away.

If there are some files/instructions for compilation of the upcoming release, I would be happy to test with arduino-ats, or if there you can update the tarball, that would be even better.

I have a fully working app now, so I can make sure I can compile arduino-ats without any modified files and then make sure the app is working. That would be real nice before the actual release.

[gmhwxi]

You can find a pre-stable release of ATS2-0.2.3 at:

http://www.ats-lang.org/Downloads.html

It is a tarball I made earlier tonight. Let me know if it works.

https://github.com/githwxi/ATS-Postiats-contrib/blob/master/contrib/arduino/
https://github.com/githwxi/ATS-Postiats-contrib/blob/master/contrib/arduino/H/pats_ccomp.h

I briefly tested the new pats_ccomp.h. It seems to be working.

[Mike Jones]

I was able to change the arduino-ats prelude to all point to the ATS2 distribution. Then remove all the files. Everything compiles including my application. 01_blink works. I'll test my application tomorrow at the office.

The only other thing hanging on is a string0.sats/dats, which is a copy of string.sats/dats with modification used by hardware_serial. I'll leave that up to Kiwamu, as he wrote the code.

Kiwamu,

We can talk over e-mail about what I did and the twi files/example. I think decoupling from ATS2 CATS files will be much cleaner. I used your Makefile changes to test this out and had no problems. So hopefully after the next release we can remove the dependencies and CAT files, and I can give yo the twi stuff.

[Mike Jones]

My app runs, but it is suddenly very slow. I need to debug to see if it is related to hardware, application code, or other.

[Hongwei Xi]

As a rule of thumb, the C code generated by Patsopt in general needs to be compiled with -O2 to

ensure that inlining is properly done.

--

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 post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/0e9ea800-2e7a-45ed-9456-3279451c9592%40googlegroups.com.

[Kiwamu Okabe]

Hi Mike,
sorry for too late reply.

On Wed, Sep 23, 2015 at 12:14 PM, Mike Jones <proc...@gmail.com> wrote:
> We can talk over e-mail about what I did and the twi files/example. I think
> decoupling from ATS2 CATS files will be much cleaner. I used your Makefile
> changes to test this out and had no problems. So hopefully after the next
> release we can remove the dependencies and CAT files, and I can give yo the
> twi stuff.

I think I can merge it into my repo.
Could you show me the running code?

Thank's,
--
Kiwamu Okabe at METASEPI DESIGN

[Mike Jones]

Kiwamu,

Attached is a patch that has twi, smbus, and changes the prelude, plus removal of cats files.

You already updated the makefile for the new release.

I tested 01_blink. Others compile, but I did not test them.

The i2c/smbus demos are specific to my PMBus hardware. If there is some standard shield everyone uses a lot, they could be modified for a more common hardware.

Mike

The twi files are from arduino

[Mike Jones]

My problem was resolved. Given that the application interacts via a client coded in Haskell over the USB, performance is not just the ATS app on the Arduino..

Anyway, thanks for partitioning the code. This helps clean up things for embedded work, and I consider my project quite successful.

I was able to grab some preexisting C code, then port the main C application to ATS, with no performance lost. It is very key that I can write code with no malloc or GC in a functional style and avoid references and arrays where possible. I can run Haskell on Linux on an Edison, but once I drop to Cortex M0 or less, ATS is the proper language.

Longer term, I am interested in getting arduino-ats working on Arduino Zero as I need that level of performance. However, the library code for Zero needs to mature, mainly that the i2c layer does not yet do a repeated start.

I don't know what the general interest is in embedded programming with functional code, but I view ATS as solving some nasty problems in embedded work.

Cheers

[Kiwamu Okabe]

Hi Mike,

On Sat, Sep 26, 2015 at 11:46 PM, Mike Jones <proc...@gmail.com> wrote:
> Attached is a patch that has twi, smbus, and changes the prelude, plus
> removal of cats files.
>
> You already updated the makefile for the new release.
>
> I tested 01_blink. Others compile, but I did not test them.
>
> The i2c/smbus demos are specific to my PMBus hardware. If there is some
> standard shield everyone uses a lot, they could be modified for a more
> common hardware.

Thank's. I merged your patch.

https://github.com/fpiot/arduino-ats/commit/a0d79410292156d34bde76c5063389f813ae5a2c

However my build has following error:

$ pwd
/home/kiwamu/src/arduino-ats/demo/i2c
$ make
patsopt -o DATS/main_dats.c.tmp -d DATS/main.dats
/home/kiwamu/src/arduino-ats/demo/i2c/DATS/main.dats: 217(line=8,
offs=1) -- 249(line=8, offs=33): error(1): the file
[{$TOP}/SATS/pmbus.sats] is not available for staloading.

Do you have the pmbus.sats file?

Thank's a lot,

[Kiwamu Okabe]

Hi Mike,

On Sun, Sep 27, 2015 at 1:08 AM, Mike Jones <proc...@gmail.com> wrote:
> Longer term, I am interested in getting arduino-ats working on Arduino Zero
> as I need that level of performance. However, the library code for Zero
> needs to mature, mainly that the i2c layer does not yet do a repeated start.

Are you interested in an application on some RTOS? I have some plan for it.

https://github.com/fpiot/mbed-ats
https://github.com/fpiot/chibios-ats

I think these applications are easy to use linear types with dataviewtype,
because they can use malloc of RTOS.


And so, I think you are better person than me to build ATS application on small
embedded system. Could you join Functional IoT project https://github.com/fpiot
with your github account?

Thank's,

[Mike jones]

You can remove the reference. The file is still an empty placeholder.

Sent from my iPad

> --
> You received this message because you are subscribed to a topic in the Google Groups "ats-lang-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/ats-lang-users/_N1xLDQ-Lgk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to ats-lang-user...@googlegroups.com.

> To post to this group, send email to ats-lan...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ats-lang-users.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAEvX6dniaW2MkL8%2Bb4rQWJeO-yb34c2gindL1iJxTYdwgTR01w%40mail.gmail.com.

[Mike jones]

I am interested, but was looking a ecos, which is mature, full featured, and I am familiar.

Sent from my iPad

> --
> You received this message because you are subscribed to a topic in the Google Groups "ats-lang-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/ats-lang-users/_N1xLDQ-Lgk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to ats-lang-user...@googlegroups.com.

> To post to this group, send email to ats-lan...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ats-lang-users.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAEvX6dkPonHcv3pXMHjpd7LdmPdpOEXh6rNQtdfceFGya1SvXA%40mail.gmail.com.

[Kiwamu Okabe]

Hi Mike,

On Tue, Sep 29, 2015 at 9:15 AM, Mike jones <proc...@gmail.com> wrote:
> You can remove the reference. The file is still an empty placeholder.

I can build your code with following patch:

https://github.com/fpiot/arduino-ats/commit/49b9bbce8ca07165f54e68bf7e45ae77b646a733

Thank's,

[Mike Jones]

Kiwamu,

That is what I expected. PMBus eventually, but not yet.

Mike