Fprintf support in CATS files effects compilation for embedded target

Google Group
1

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

2

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.On Sat, Sep 19, 2015 at 3:52 PM, Mike Jones proc...@gmail.com wrote:

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

–
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
https://groups.google.com/d/msgid/ats-lang-users/66e072f9-4651-427a-b2ce-4db96b2103ea%40googlegroups.com?utm_medium=email&utm_source=footer
.

3

You can remove the reference. The file is still an empty placeholder.> On Sep 28, 2015, at 7:28 AM, Kiwamu Okabe kiw...@debian.or.jp wrote:

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.

Import Mike's ats23.patch · fpiot/arduino-ats@a0d7941 · GitHub

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 at METASEPI DESIGN

–
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.

4

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?On Sunday, September 20, 2015 at 11:10:20 AM UTC-4, Mike Jones wrote:

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

5

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.

I briefly tested the new pats_ccomp.h. It seems to be working.On Tuesday, September 22, 2015 at 9:21:20 PM UTC-4, Mike Jones wrote:

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.

6

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.On Sunday, September 20, 2015 at 4:24:17 PM UTC-6, gmhwxi wrote:

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.

On Sunday, September 20, 2015 at 5:17:26 PM UTC-4, Mike Jones wrote:

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.

On Sunday, September 20, 2015 at 10:39:04 AM UTC-6, gmhwxi wrote:

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?

On Sunday, September 20, 2015 at 11:10:20 AM UTC-4, Mike Jones wrote:

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

7

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.On Sunday, September 20, 2015 at 10:39:04 AM UTC-6, gmhwxi wrote:

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?

On Sunday, September 20, 2015 at 11:10:20 AM UTC-4, Mike Jones wrote:

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

8

I am interested, but was looking a ecos, which is mature, full featured, and I am familiar.> On Sep 28, 2015, at 7:35 AM, Kiwamu Okabe kiw...@debian.or.jp wrote:

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.

GitHub - fpiot/mbed-ats: ATS programing on mbed platform
GitHub - fpiot/chibios-ats: ATS programing on ChibiOS/RT

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 Functional IoT · GitHub
with your github account?

Thank’s,

Kiwamu Okabe at METASEPI DESIGN

–
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.

9

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.

10

Kiwamu,

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

MikeOn Monday, September 28, 2015 at 8:17:13 PM UTC-6, Kiwamu Okabe wrote:

Hi Mike,

On Tue, Sep 29, 2015 at 9:15 AM, Mike jones <pro...@gmail.com <javascript:>> wrote:

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

I can build your code with following patch:

Remove pmbus.sats · fpiot/arduino-ats@49b9bbc · GitHub

Thank’s,

Kiwamu Okabe at METASEPI DESIGN

11

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.

CheersOn Wednesday, September 23, 2015 at 9:23:20 AM UTC-6, gmhwxi wrote:

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.

On Wed, Sep 23, 2015 at 11:15 AM, Mike Jones <pro...@gmail.com <javascript:>> wrote:

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.

On Tuesday, September 22, 2015 at 9:14:28 PM UTC-6, Mike Jones wrote:

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.

–
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...@googlegroups.com <javascript:>.
To post to this group, send email to ats-l...@googlegroups.com
<javascript:>.
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
https://groups.google.com/d/msgid/ats-lang-users/0e9ea800-2e7a-45ed-9456-3279451c9592%40googlegroups.com?utm_medium=email&utm_source=footer
.

12

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.

13

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.On Sunday, September 20, 2015 at 5:17:26 PM UTC-4, Mike Jones wrote:

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.

On Sunday, September 20, 2015 at 10:39:04 AM UTC-6, gmhwxi wrote:

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?

On Sunday, September 20, 2015 at 11:10:20 AM UTC-4, Mike Jones wrote:

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

14

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.On Monday, September 21, 2015 at 11:20:49 AM UTC-6, William Blair wrote:

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

Am Samstag, 19. September 2015 15:52:57 UTC-4 schrieb 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

15

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.satsAm Samstag, 19. September 2015 15:52:57 UTC-4 schrieb 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

16

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

17

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.On Monday, September 21, 2015 at 1:07:33 AM UTC-4, Mike Jones wrote:

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.

On Sunday, September 20, 2015 at 4:24:17 PM UTC-6, gmhwxi wrote:

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.

On Sunday, September 20, 2015 at 5:17:26 PM UTC-4, Mike Jones wrote:

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.

On Sunday, September 20, 2015 at 10:39:04 AM UTC-6, gmhwxi wrote:

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?

On Sunday, September 20, 2015 at 11:10:20 AM UTC-4, Mike Jones wrote:

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

18

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.On Wed, Sep 23, 2015 at 11:15 AM, Mike Jones proc...@gmail.com wrote:

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.

On Tuesday, September 22, 2015 at 9:14:28 PM UTC-6, Mike Jones wrote:

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.

–
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
https://groups.google.com/d/msgid/ats-lang-users/0e9ea800-2e7a-45ed-9456-3279451c9592%40googlegroups.com?utm_medium=email&utm_source=footer
.

19

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 arduinoOn Thursday, September 24, 2015 at 1:29:33 AM UTC-6, Kiwamu Okabe wrote:

Hi Mike,
sorry for too late reply.

On Wed, Sep 23, 2015 at 12:14 PM, Mike Jones <pro...@gmail.com <javascript:>> 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

ats23.patch (142 KB)

20

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.On Tuesday, September 22, 2015 at 9:14:28 PM UTC-6, Mike Jones wrote:

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.