Is this code to be commented on?

[morido]

Is this code actually supposed to be human-readable. I.e. are we encouraged to examine it and pose questions?

If so, here are three:

1. Apparently, this code is auto-generated. So I would expect it to follow a uniform style. However, members of structs are accessed both through (*x).y and via x->y. Is there any reason for this?
2. The casting functions are often dead code. E.g. consider CAST_Int_to_D_CYCLOC_TM_conversions(). This essentially performs an int to int conversion.
   Now dead code is not per se a problem. However, I am inclined to assume that the typedef'd target type D_CYCLOC is indeed more constrained than the source type kcg_int. So there ought to be some logic here...
   Or did you perhaps define a valid range for D_CYCLOC inside SCADE but its KCG component can preserve this constraint only when targeting Ada and not with C (which would be really bad)?
3. I tried to trace the origins of D_CYCLOC in hopes of finding a sanity check for its contents at some earlier point. Unfortunately, I had to stop when stumbling on kcg_copy_array_int_8(), which is essentially defined in a file called kcg_assign.h. However, this file does not seem to be present anywhere in the repository. Am I missing something here?

Perhaps someone can enlighten me?

Cheers,
Moritz

[JakobGartner]

Jakob Gaertner

LEA Railergy
Am Mittleren Moos 48
86167 Augsburg

j.gaertner@railergy.com
+49 821 907802-0
+49 151 25387841

On 05.08.2015, at 20:39, Moritz Dorka notifications@github.com wrote:

Is this code actually supposed to be human-readable. I.e. are we encouraged
to examine it and pose questions?

Hello

Attempting some first answers

If so, here are three:

Apparently, this code is auto-generated. So I would expect it to follow
a uniform style. However, members of structs are accessed both through
(*x).y and via x->y. Is there any reason for this?

KCG generates code, but it is not a mere template- composer.
Technically it is comparable to a compiler , with the important difference
that it is backed by certificates for any relevant standard in the safety
critical world including EN 50128 SIL3/4.
The essential value of these certificates is that it guarantees that the
behavior of the generated code equals the behavior of the model.
In addition all objectives of the standard are guaranteed to be met.
Criteria for human -readable code are not really applicable.
(There is for example a long discussion concerning MISRA... Which is really
obsolete )
C- code from KCG point of view has a similar role as object code from for
example a GCC point pic view.

The casting functions are often dead code. E.g. consider
CAST_Int_to_D_CYCLOC_TM_conversions()

srcAndBinary/Green openETCS Non-Vital Demonstrator/Source Code/Source Code ETCS Onboard Unit System/Generated_Code/CAST_Int_to_D_CYCLOC_TM_conversions.c

Line 11 in 434737f

D_CYCLOC CAST_Int_to_D_CYCLOC_TM_conversions(

.
This essentially performs an int to int conversion.
Now dead code is not per se a problem. However, I am inclined to assume
that the typedef'd target type D_CYCLOC is indeed more constrained than
the source type kcg_int. So there ought to be some logic here...
Or did you perhaps define a valid range for D_CYCLOC inside SCADE but
its KCG component can preserve this constraint only when targeting Ada and
not with C (which would be really bad)?

This is not a question related to code generation itself.
It is true that this is an int to int conversion .
However these libraries do provide a range check which is not yet connected
to the upcoming exception management. At the moment the data flows end in a
SCADE terminator.
Which means that KCG doesn't generate code (in the higher optimization
levels , Data flow leading to a terminator is deleted )
However in the next iteration , Logic for exception handling well be added .

I tried to trace the origins of D_CYCLOC in hopes of finding a sanity
check for its contents at some earlier point. Unfortunately, I had to stop
when stumbling on kcg_copy_array_int_8()

srcAndBinary/Green openETCS Non-Vital Demonstrator/Source Code/Source Code ETCS Onboard Unit System/Generated_Code/C_P058_compr_onboard_TM_conversions.c

Line 29 in 434737f

kcg_copy_array_int_8(&_L1, (array_int_8 *) &(*PacketData)[0]);

,
which is essentially defined in a file called kcg_assign.h. However,
this file does not seem to be present anywhere in the repository. Am I
missing something here?

Will check

Perhaps someone can enlighten me?

Cheers,
Moritz

—
Reply to this email directly or view it on GitHub
#2.