Loading ...
Sorry, an error occurred while loading the content.

Conditional compilation - how to make it work?

Expand Messages
  • a_b_aldus
    Hello, is there a way to make following fragment (this is NOT proper JAL) work: const PARAM = 1 if (PARAM == 1) then var byte values[4] else if (PARAM == 2)
    Message 1 of 22 , Sep 1, 2010
    • 0 Attachment
      Hello,
      is there a way to make following fragment (this is NOT proper JAL)
      work:

      const PARAM = 1

      if (PARAM == 1) then
      var byte values[4]
      else if (PARAM == 2) then
      var word values[4]
      end if

      values[1] = SOMETHING

      -- generally JAL compiles if with constant condition as it is
      a preprocessor directive, and as I know this is the reasone why
      there is no real preprocessor in JAL. But problem gere is the
      scope - values[] in the assignment is not defined - definition
      scope ends with 'end if'.

      May be this is already solved with JALv2 - I'm more familiar with
      v1.

      Arcady
    • Matt
      I prefer this: const PARAM = 1 var byte*PARAM values[4] so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the variable will be byte*2 (a
      Message 2 of 22 , Sep 1, 2010
      • 0 Attachment
        I prefer this:

        const PARAM = 1
        var byte*PARAM values[4]

        so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the variable will be byte*2 (a word)

        Matt.

        --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
        >
        > Hello,
        > is there a way to make following fragment (this is NOT proper JAL)
        > work:
        >
        > const PARAM = 1
        >
        > if (PARAM == 1) then
        > var byte values[4]
        > else if (PARAM == 2) then
        > var word values[4]
        > end if
        >
        > values[1] = SOMETHING
        >
        > -- generally JAL compiles if with constant condition as it is
        > a preprocessor directive, and as I know this is the reasone why
        > there is no real preprocessor in JAL. But problem gere is the
        > scope - values[] in the assignment is not defined - definition
        > scope ends with 'end if'.
        >
        > May be this is already solved with JALv2 - I'm more familiar with
        > v1.
        >
        > Arcady
        >
      • a_b_aldus
        Matt, It s not really an answer - you used something I only used in my question to illustrate the point. This is a generic question of declarations scope -
        Message 3 of 22 , Sep 6, 2010
        • 0 Attachment
          Matt,

          It's not really an answer - you used something I only used in
          my question to illustrate the point. This is a generic question
          of declarations scope - could I make a declaration in one if-block
          to be visible outside the block and if not what could be done?

          Arcady

          --- In jallist@yahoogroups.com, "Matt" <matthewschinkel@...> wrote:
          >
          > I prefer this:
          >
          > const PARAM = 1
          > var byte*PARAM values[4]
          >
          > so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the variable will be byte*2 (a word)
          >
          > Matt.
          >
          > --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@> wrote:
          > >
          > > Hello,
          > > is there a way to make following fragment (this is NOT proper JAL)
          > > work:
          > >
          > > const PARAM = 1
          > >
          > > if (PARAM == 1) then
          > > var byte values[4]
          > > else if (PARAM == 2) then
          > > var word values[4]
          > > end if
          > >
          > > values[1] = SOMETHING
          > >
          > > -- generally JAL compiles if with constant condition as it is
          > > a preprocessor directive, and as I know this is the reasone why
          > > there is no real preprocessor in JAL. But problem gere is the
          > > scope - values[] in the assignment is not defined - definition
          > > scope ends with 'end if'.
          > >
          > > May be this is already solved with JALv2 - I'm more familiar with
          > > v1.
          > >
          > > Arcady
          > >
          >
        • Sebastien Lelong
          Hi, IIRC you may need to use include , that is, putting your variable into another file. In this case, content of this file will be imported into current
          Message 4 of 22 , Sep 6, 2010
          • 0 Attachment
            Hi,

            IIRC you may need to use "include", that is, putting your variable into
            another file. In this case, content of this file will be "imported" into
            current scope.

            Cheers,
            Seb



            2010/9/6 a_b_aldus <a_b_aldus@...>

            >
            >
            > Matt,
            >
            > It's not really an answer - you used something I only used in
            > my question to illustrate the point. This is a generic question
            > of declarations scope - could I make a declaration in one if-block
            > to be visible outside the block and if not what could be done?
            >
            > Arcady
            >
            >
            > --- In jallist@yahoogroups.com <jallist%40yahoogroups.com>, "Matt"
            > <matthewschinkel@...> wrote:
            > >
            > > I prefer this:
            > >
            > > const PARAM = 1
            > > var byte*PARAM values[4]
            > >
            > > so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the
            > variable will be byte*2 (a word)
            > >
            > > Matt.
            > >
            > > --- In jallist@yahoogroups.com <jallist%40yahoogroups.com>, "a_b_aldus"
            > <a_b_aldus@> wrote:
            > > >
            > > > Hello,
            > > > is there a way to make following fragment (this is NOT proper JAL)
            > > > work:
            > > >
            > > > const PARAM = 1
            > > >
            > > > if (PARAM == 1) then
            > > > var byte values[4]
            > > > else if (PARAM == 2) then
            > > > var word values[4]
            > > > end if
            > > >
            > > > values[1] = SOMETHING
            > > >
            > > > -- generally JAL compiles if with constant condition as it is
            > > > a preprocessor directive, and as I know this is the reasone why
            > > > there is no real preprocessor in JAL. But problem gere is the
            > > > scope - values[] in the assignment is not defined - definition
            > > > scope ends with 'end if'.
            > > >
            > > > May be this is already solved with JALv2 - I'm more familiar with
            > > > v1.
            > > >
            > > > Arcady
            > > >
            > >
            >
            >
            >



            --
            S´┐Żbastien Lelong
            http://www.sirloon.net
            http://sirbot.org


            [Non-text portions of this message have been removed]
          • Matt
            Ok, I tried to come up with a solution for the problem you gave in your example. Is there another reason for declaring in the if statement? Maybe give us an
            Message 5 of 22 , Sep 6, 2010
            • 0 Attachment
              Ok, I tried to come up with a solution for the problem you gave in your example. Is there another reason for declaring in the if statement? Maybe give us an example of the problem you are trying to solve.

              Matt.

              --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
              >
              > Matt,
              >
              > It's not really an answer - you used something I only used in
              > my question to illustrate the point. This is a generic question
              > of declarations scope - could I make a declaration in one if-block
              > to be visible outside the block and if not what could be done?
              >
              > Arcady
              >
              > --- In jallist@yahoogroups.com, "Matt" <matthewschinkel@> wrote:
              > >
              > > I prefer this:
              > >
              > > const PARAM = 1
              > > var byte*PARAM values[4]
              > >
              > > so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the variable will be byte*2 (a word)
              > >
              > > Matt.
              > >
              > > --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@> wrote:
              > > >
              > > > Hello,
              > > > is there a way to make following fragment (this is NOT proper JAL)
              > > > work:
              > > >
              > > > const PARAM = 1
              > > >
              > > > if (PARAM == 1) then
              > > > var byte values[4]
              > > > else if (PARAM == 2) then
              > > > var word values[4]
              > > > end if
              > > >
              > > > values[1] = SOMETHING
              > > >
              > > > -- generally JAL compiles if with constant condition as it is
              > > > a preprocessor directive, and as I know this is the reasone why
              > > > there is no real preprocessor in JAL. But problem gere is the
              > > > scope - values[] in the assignment is not defined - definition
              > > > scope ends with 'end if'.
              > > >
              > > > May be this is already solved with JALv2 - I'm more familiar with
              > > > v1.
              > > >
              > > > Arcady
              > > >
              > >
              >
            • jsuijs
              Hi Arcady, I wonder why you asked the question in the first place. Did you try the code construct you suggested? And what are the results? If I would have
              Message 6 of 22 , Sep 6, 2010
              • 0 Attachment
                Hi Arcady,

                I wonder why you asked the question in the first place. Did you try the code construct you suggested? And what are the results?

                If I would have answered by heart, I'd say this is possible since 2006. But to be sure I tried your code and with the syntax errors fixed, it compiles with flying colors.

                So what's the problem?

                Joep


                --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
                >
                > Matt,
                >
                > It's not really an answer - you used something I only used in
                > my question to illustrate the point. This is a generic question
                > of declarations scope - could I make a declaration in one if-block
                > to be visible outside the block and if not what could be done?
                >
                > Arcady
                >
                > --- In jallist@yahoogroups.com, "Matt" <matthewschinkel@> wrote:
                > >
                > > I prefer this:
                > >
                > > const PARAM = 1
                > > var byte*PARAM values[4]
                > >
                > > so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the variable will be byte*2 (a word)
                > >
                > > Matt.
                > >
                > > --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@> wrote:
                > > >
                > > > Hello,
                > > > is there a way to make following fragment (this is NOT proper JAL)
                > > > work:
                > > >
                > > > const PARAM = 1
                > > >
                > > > if (PARAM == 1) then
                > > > var byte values[4]
                > > > else if (PARAM == 2) then
                > > > var word values[4]
                > > > end if
                > > >
                > > > values[1] = SOMETHING
                > > >
                > > > -- generally JAL compiles if with constant condition as it is
                > > > a preprocessor directive, and as I know this is the reasone why
                > > > there is no real preprocessor in JAL. But problem gere is the
                > > > scope - values[] in the assignment is not defined - definition
                > > > scope ends with 'end if'.
                > > >
                > > > May be this is already solved with JALv2 - I'm more familiar with
                > > > v1.
                > > >
                > > > Arcady
                > > >
                > >
                >
              • a_b_aldus
                Joep, Thanks. I did not work with JAL since v1, and from there my question. I downloaded v2 and tried few tests and see that similar construction does work and
                Message 7 of 22 , Sep 6, 2010
                • 0 Attachment
                  Joep,

                  Thanks. I did not work with JAL since v1, and from there my
                  question. I downloaded v2 and tried few tests and see that
                  similar construction does work and figured out the way it
                  has been done - as much aspects of jal - by the hack :) Here
                  hack is that if-statement is recognized as 'compiler directive',
                  so it does not open new scope and then if I put block/end block
                  inside - it stops work. So result for the language is 'what looks
                  like ABC does not really work like ABC if there are some subtle
                  changes in the context (in this case variable changed to the
                  constant).

                  Anyway it does work now. As to the question by some other members -
                  I want the source which could be reconfigured with few constants,
                  generally I want what C preprocessor could do. Such reconfigurable
                  code definitely would include disagreeing declarations like in:

                  const PARAM = 1
                  if (PARAM == 1) then
                  -- block -- DOES NOT work if uncommented
                  var byte arr[2]

                  function array'get() return byte is
                  return arr[1]
                  end function
                  -- end block
                  else
                  var byte array
                  end if

                  forever loop
                  PORTA = array -- static var OR access function
                  end loop

                  with this example no trick like byte*CONST could work.

                  Arcady

                  --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@...> wrote:
                  >
                  > Hi Arcady,
                  >
                  > I wonder why you asked the question in the first place. Did you try the code construct you suggested? And what are the results?
                  >
                  > If I would have answered by heart, I'd say this is possible since 2006. But to be sure I tried your code and with the syntax errors fixed, it compiles with flying colors.
                  >
                  > So what's the problem?
                  >
                  > Joep
                  >
                  >
                  > --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@> wrote:
                  > >
                  > > Matt,
                  > >
                  > > It's not really an answer - you used something I only used in
                  > > my question to illustrate the point. This is a generic question
                  > > of declarations scope - could I make a declaration in one if-block
                  > > to be visible outside the block and if not what could be done?
                  > >
                  > > Arcady
                  > >
                  > > --- In jallist@yahoogroups.com, "Matt" <matthewschinkel@> wrote:
                  > > >
                  > > > I prefer this:
                  > > >
                  > > > const PARAM = 1
                  > > > var byte*PARAM values[4]
                  > > >
                  > > > so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the variable will be byte*2 (a word)
                  > > >
                  > > > Matt.
                  > > >
                  > > > --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@> wrote:
                  > > > >
                  > > > > Hello,
                  > > > > is there a way to make following fragment (this is NOT proper JAL)
                  > > > > work:
                  > > > >
                  > > > > const PARAM = 1
                  > > > >
                  > > > > if (PARAM == 1) then
                  > > > > var byte values[4]
                  > > > > else if (PARAM == 2) then
                  > > > > var word values[4]
                  > > > > end if
                  > > > >
                  > > > > values[1] = SOMETHING
                  > > > >
                  > > > > -- generally JAL compiles if with constant condition as it is
                  > > > > a preprocessor directive, and as I know this is the reasone why
                  > > > > there is no real preprocessor in JAL. But problem gere is the
                  > > > > scope - values[] in the assignment is not defined - definition
                  > > > > scope ends with 'end if'.
                  > > > >
                  > > > > May be this is already solved with JALv2 - I'm more familiar with
                  > > > > v1.
                  > > > >
                  > > > > Arcady
                  > > > >
                  > > >
                  > >
                  >
                • jsuijs
                  Hi Arcady, So you could have checked before asking ;) If you have not done this already, you might go through the jallib startersguide that covers quite a lot
                  Message 8 of 22 , Sep 6, 2010
                  • 0 Attachment
                    Hi Arcady,

                    So you could have checked before asking ;)

                    If you have not done this already, you might go through the jallib startersguide that covers quite a lot of details along with the basics. The feature at hand is not includes, since I estimated it is way beyond the scope of the audience.

                    By the way, the feature at hand is called 'conditional compile'. This is any contiditional statement of which the expression is a compile time constant. Iirc only the 'true' code is compiled just if the conditional expression did not exist - so no extra scope is created for this (I trust Kyle will step in if this is not accurate or complete).

                    And yes, it is not easy to see if a statement is a normal condition of a conditional compile. This gives unintended inefficiency when an expression is not constant while it should. However, it does provide the option to do calculations compile-time when they are fixed and use the same code (with a var in stead of a const) to have the code for runtime calculations.

                    Joep

                    --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
                    >
                    > Joep,
                    >
                    > Thanks. I did not work with JAL since v1, and from there my
                    > question. I downloaded v2 and tried few tests and see that
                    > similar construction does work and figured out the way it
                    > has been done - as much aspects of jal - by the hack :) Here
                    > hack is that if-statement is recognized as 'compiler directive',
                    > so it does not open new scope and then if I put block/end block
                    > inside - it stops work. So result for the language is 'what looks
                    > like ABC does not really work like ABC if there are some subtle
                    > changes in the context (in this case variable changed to the
                    > constant).
                    >
                    > Anyway it does work now. As to the question by some other members -
                    > I want the source which could be reconfigured with few constants,
                    > generally I want what C preprocessor could do. Such reconfigurable
                    > code definitely would include disagreeing declarations like in:
                    >
                    > const PARAM = 1
                    > if (PARAM == 1) then
                    > -- block -- DOES NOT work if uncommented
                    > var byte arr[2]
                    >
                    > function array'get() return byte is
                    > return arr[1]
                    > end function
                    > -- end block
                    > else
                    > var byte array
                    > end if
                    >
                    > forever loop
                    > PORTA = array -- static var OR access function
                    > end loop
                    >
                    > with this example no trick like byte*CONST could work.
                    >
                    > Arcady
                    >
                    > --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@> wrote:
                    > >
                    > > Hi Arcady,
                    > >
                    > > I wonder why you asked the question in the first place. Did you try the code construct you suggested? And what are the results?
                    > >
                    > > If I would have answered by heart, I'd say this is possible since 2006. But to be sure I tried your code and with the syntax errors fixed, it compiles with flying colors.
                    > >
                    > > So what's the problem?
                    > >
                    > > Joep
                    > >
                    > >
                    > > --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@> wrote:
                    > > >
                    > > > Matt,
                    > > >
                    > > > It's not really an answer - you used something I only used in
                    > > > my question to illustrate the point. This is a generic question
                    > > > of declarations scope - could I make a declaration in one if-block
                    > > > to be visible outside the block and if not what could be done?
                    > > >
                    > > > Arcady
                    > > >
                    > > > --- In jallist@yahoogroups.com, "Matt" <matthewschinkel@> wrote:
                    > > > >
                    > > > > I prefer this:
                    > > > >
                    > > > > const PARAM = 1
                    > > > > var byte*PARAM values[4]
                    > > > >
                    > > > > so if PARAM = 1 the variable will be byte*1 (a byte) and if PARAM = 2 the variable will be byte*2 (a word)
                    > > > >
                    > > > > Matt.
                    > > > >
                    > > > > --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@> wrote:
                    > > > > >
                    > > > > > Hello,
                    > > > > > is there a way to make following fragment (this is NOT proper JAL)
                    > > > > > work:
                    > > > > >
                    > > > > > const PARAM = 1
                    > > > > >
                    > > > > > if (PARAM == 1) then
                    > > > > > var byte values[4]
                    > > > > > else if (PARAM == 2) then
                    > > > > > var word values[4]
                    > > > > > end if
                    > > > > >
                    > > > > > values[1] = SOMETHING
                    > > > > >
                    > > > > > -- generally JAL compiles if with constant condition as it is
                    > > > > > a preprocessor directive, and as I know this is the reasone why
                    > > > > > there is no real preprocessor in JAL. But problem gere is the
                    > > > > > scope - values[] in the assignment is not defined - definition
                    > > > > > scope ends with 'end if'.
                    > > > > >
                    > > > > > May be this is already solved with JALv2 - I'm more familiar with
                    > > > > > v1.
                    > > > > >
                    > > > > > Arcady
                    > > > > >
                    > > > >
                    > > >
                    > >
                    >
                  • zz
                    Greetings, ... Yes, this is an absolutely awful hack but in the early days I was told to be as close to JALv1 compatible as possible. On this point I should
                    Message 9 of 22 , Sep 9, 2010
                    • 0 Attachment
                      Greetings,


                      --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
                      >
                      > Thanks. I did not work with JAL since v1, and from there my
                      > question. I downloaded v2 and tried few tests and see that
                      > similar construction does work and figured out the way it
                      > has been done - as much aspects of jal - by the hack :) Here
                      > hack is that if-statement is recognized as 'compiler directive',
                      > so it does not open new scope and then if I put block/end block
                      > inside - it stops work. So result for the language is 'what looks
                      > like ABC does not really work like ABC if there are some subtle
                      > changes in the context (in this case variable changed to the
                      > constant).

                      Yes, this is an absolutely awful hack but in the early days I was told to be as close to JALv1 compatible as possible. On this point I should never have ceded. Oh well.

                      Using this without copious comments explaining what's happening is even worse. There is a compiler switch (-W[no-]directives) to at least warn you when these are found.

                      --kyle
                    • a_b_aldus
                      I somehow expected that v2 is the same as v1 but improved compiler. Looks like it s not quite so. Problem is also that external preprocessor like CPP cannot be
                      Message 10 of 22 , Sep 10, 2010
                      • 0 Attachment
                        I somehow expected that v2 is the same as v1 but improved compiler.
                        Looks like it's not quite so. Problem is also that external
                        preprocessor like CPP cannot be used as it needs source compliant
                        with C tokens rules. Going with m4 - ok, we DIY ppl are frequently
                        "masochistic" but not to such extent...

                        Arcady

                        --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@...> wrote:
                        >
                        > Hi Arcady,
                        >
                        > So you could have checked before asking ;)
                      • Sebastien Lelong
                        Hi Arcady, Why m4 would be so masochistic ? Can you give some thoughts ? Cheers, Seb 2010/9/11 a_b_aldus ... [Non-text portions of
                        Message 11 of 22 , Oct 8, 2010
                        • 0 Attachment
                          Hi Arcady,

                          Why m4 would be so "masochistic" ? Can you give some thoughts ?

                          Cheers,
                          Seb

                          2010/9/11 a_b_aldus <a_b_aldus@...>

                          >
                          >
                          > I somehow expected that v2 is the same as v1 but improved compiler.
                          > Looks like it's not quite so. Problem is also that external
                          > preprocessor like CPP cannot be used as it needs source compliant
                          > with C tokens rules. Going with m4 - ok, we DIY ppl are frequently
                          > "masochistic" but not to such extent...
                          >
                          >
                          > Arcady
                          >


                          [Non-text portions of this message have been removed]
                        • a_b_aldus
                          Sebastien, Did you ever use it? If so and if you are satisfied with it - then it could work for you. For generic population (me included) it is to criptic and
                          Message 12 of 22 , Oct 8, 2010
                          • 0 Attachment
                            Sebastien,

                            Did you ever use it? If so and if you are satisfied with it -
                            then it could work for you. For generic population (me included)
                            it is to criptic and chaotic. It's powerful but complicated.
                            There is some contradiction in goals with JAL, this is why I
                            would not recommend to use it. But this recomendation is "in
                            generic" - if we discuss the preprocessor been the part of JAL
                            language/distributive. Any person could use any tool one likes -
                            problem is - does it worst it? I believe that preprocessor would
                            be very useful in creating generic libraries, where we are forced
                            to create almost identical text again and again.

                            Arcady

                            PS Let me repeat again - any preprocessor could be used or no one
                            at all. But some are better not to be introduced based on generic
                            population of JAL users not to be Unix pros.

                            --- In jallist@yahoogroups.com, Sebastien Lelong <sebastien.lelong@...> wrote:
                            >
                            > Hi Arcady,
                            >
                            > Why m4 would be so "masochistic" ? Can you give some thoughts ?
                            >
                            > Cheers,
                            > Seb
                            >
                            > 2010/9/11 a_b_aldus <a_b_aldus@...>
                            >
                            > >
                            > >
                            > > I somehow expected that v2 is the same as v1 but improved compiler.
                            > > Looks like it's not quite so. Problem is also that external
                            > > preprocessor like CPP cannot be used as it needs source compliant
                            > > with C tokens rules. Going with m4 - ok, we DIY ppl are frequently
                            > > "masochistic" but not to such extent...
                            > >
                            > >
                            > > Arcady
                            > >
                            >
                            >
                            > [Non-text portions of this message have been removed]
                            >
                          • Wouter van Ooijen
                            ... IMHO for library creation with lots of duplication it is better to use a program (likely not Jal), running on your PC, that writes the libraries. I prefer
                            Message 13 of 22 , Oct 8, 2010
                            • 0 Attachment
                              > I believe that preprocessor would
                              > be very useful in creating generic libraries, where we are forced
                              > to create almost identical text again and again.

                              IMHO for library creation with lots of duplication it is better to use a
                              program (likely not Jal), running on your PC, that writes the libraries.
                              I prefer Python for this type of job (in fact I prefer Python for nearly
                              everything that runs on a PC).

                              But this is certainly not the the advisable route for writing an
                              application.

                              --

                              Wouter van Ooijen

                              -- -------------------------------------------
                              Van Ooijen Technische Informatica: www.voti.nl
                              consultancy, development, PICmicro products
                              docent Hogeschool van Utrecht: www.voti.nl/hvu
                            • jsuijs
                              I used M4 with jal a long time ago. The major disadvantage of this was not the preprocessor itself, but the fact that you need to create an intermediate JAL
                              Message 14 of 22 , Oct 8, 2010
                              • 0 Attachment
                                I used M4 with jal a long time ago. The major disadvantage of this was not the preprocessor itself, but the fact that you need to create an intermediate JAL file, on which the compiler acts and reports errors & warnings. So you get Error on line 150, which is in fact line 87 in the file you're working on.

                                In C, the preprocessor seems to be an integral part of the compiler. I don't know how this is with other languages...

                                Joep
                              • Wouter van Ooijen
                                ... It is not. The trick is that it produces directives to the compiler (.line ... iirc) to adjust its notion of where it is in the source, so error messages
                                Message 15 of 22 , Oct 8, 2010
                                • 0 Attachment
                                  > In C, the preprocessor seems to be an integral part of the compiler. I
                                  > don't know how this is with other languages...

                                  It is not. The trick is that it produces directives to the compiler
                                  (.line ... iirc) to adjust its notion of where it is in the source, so
                                  error messages will report the 'correct' source line.

                                  --

                                  Wouter van Ooijen

                                  -- -------------------------------------------
                                  Van Ooijen Technische Informatica: www.voti.nl
                                  consultancy, development, PICmicro products
                                  docent Hogeschool van Utrecht: www.voti.nl/hvu
                                • jsuijs
                                  ... That s not too complex. I guess the compiler calls the preprocessor, so it is aware of the original filename and works on includes too? If we had these
                                  Message 16 of 22 , Oct 9, 2010
                                  • 0 Attachment
                                    --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@...> wrote:
                                    > The trick is that it produces directives to the compiler
                                    > (.line ... iirc) to adjust its notion of where it is in the source,
                                    > so error messages will report the 'correct' source line.

                                    That's not too complex. I guess the compiler calls the preprocessor, so it is aware of the original filename and works on includes too?
                                    If we had these features in the JAL compiler, we could give preprocessors a try - generic ones (macros) or maybe specific ones for stuff like structures...

                                    Joep
                                  • Wouter van Ooijen
                                    ... no, the .line directive can be followed by a line number, and optionally a source file name. -- Wouter van Ooijen --
                                    Message 17 of 22 , Oct 9, 2010
                                    • 0 Attachment
                                      > > The trick is that it produces directives to the compiler
                                      > > (.line ... iirc) to adjust its notion of where it is in the source,
                                      > > so error messages will report the 'correct' source line.
                                      >
                                      > That's not too complex. I guess the compiler calls the preprocessor, so
                                      > it is aware of the original filename and works on includes too?

                                      no, the .line directive can be followed by a line number, and optionally
                                      a source file name.

                                      --

                                      Wouter van Ooijen

                                      -- -------------------------------------------
                                      Van Ooijen Technische Informatica: www.voti.nl
                                      consultancy, development, PICmicro products
                                      docent Hogeschool van Utrecht: www.voti.nl/hvu
                                    • a_b_aldus
                                      ... Generally (sic!) C-compiler contains 3 (or more) parts - driver (generally called CC) - is accepts options and file names and figures out exact treatment
                                      Message 18 of 22 , Oct 10, 2010
                                      • 0 Attachment
                                        --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@...> wrote:
                                        > That's not too complex. I guess the compiler calls the preprocessor, so it is aware of the original filename and works on includes too?

                                        Generally (sic!) C-compiler contains 3 (or more) parts - driver
                                        (generally called CC) - is accepts options and file names and
                                        figures out exact treatment every file needs (based on file
                                        extension). Then there is a preprocessor (lets say it's called
                                        CPP) - it takes .c files and list of include directories (!)
                                        and does all preprocessing creating plain C file. This file
                                        does not contain any comments and all substitutions and includes
                                        are done. To help next phase to report problems relative to
                                        original files preprocessor lefts out special directive
                                        "#line LINE FILE" which forces parser to THINK that this line
                                        comes from line LINE of file FILE - simple... Now the last
                                        (or not) stage (CC1) parses C-code and creates assembler code
                                        or directly object file (this is NOT the normal UNIX way, but
                                        some complilers do it so). Next step - CC calls linker to
                                        create executable from object files. This is very flexible and
                                        helps to separate different functionality into different programs -
                                        preprocessor could preprocess any files, not only C, and one could
                                        compile for example Fortran files just by instructing CC that
                                        files of extention .f should be first passed thru the f2c
                                        program.

                                        Unfortunately this is not the way JAL works - JAL is integral
                                        compiler. This is (possible) dictated by the original author
                                        desire to keep it simple and by lack of separate compiled
                                        units in the language - so .jal file directly got converted into
                                        .hex file.

                                        > If we had these features in the JAL compiler, we could give preprocessors a try - generic ones (macros) or maybe specific ones for stuff like structures...

                                        If JAL compiler to be modified to support: (1) #line directive and
                                        (2) special case of '' representing regular apostrophe ('put and
                                        'get) so CPP does not chock on "unterminated character constant"
                                        and one creates simple "driver" (it could be even simple script)
                                        that calls CPP, creates intermediate file, and then calls JAL
                                        then it would work. Actually it does work for me (just as an
                                        experiment). There are files large_array_X.jal in the JALLIB, those
                                        are implementing byte/word/dword arrays bigger then 256 bytes each.
                                        Due to the structure of the JAL, use is kind of tricky - you have
                                        to define some constants and include the appropriate
                                        large_array_X.jal file and it would create code and declare
                                        memory to work with array called large_array_X[]. To create second
                                        array one have to include file with different name (and there are
                                        only four of those). Those 4 files are 150Kbytes and mostly are
                                        repeating again and again same text with some minor changes. What
                                        I did as an experiment - I rewrote those files and created la.jal
                                        of size 3.5 Kbytes. To use one writes:

                                        // first array is buffer of 400 bytes
                                        #define LAEL 1 // element size - 1 byte
                                        #define LASZ 400 // number of elements
                                        #define LANAME buffer // name of the array
                                        #include "la.jal"

                                        This is C preprocessor so there is no reason not to use C
                                        comments /**/ as well as // (C++ and GCC). This exact
                                        process (with different values) could be repeated ANY
                                        amount of times (limited by available memory amount).

                                        After preprocessing is done code generated is minimal:

                                        var byte _LA_buffer1 [ 256 ]
                                        var byte _LA_buffer1 [ 400 - 256 *1 ]
                                        function buffer ''get(word in address) return byte is
                                        var byte data
                                        if (address > 256 * ((400 + 256 - 1) / 256 ) )
                                        data = 0
                                        elsif (( address ) >= 256 *( 1 )) then
                                        data = _LA_buffer1 [ ( address ) - 256 *( 1 ) ]
                                        else
                                        data = _LA_buffer0 [ address ]
                                        return data
                                        end function
                                        procedure buffer ''put (word in address, byte in data) is
                                        if (address > 256 * ((400 + 256 - 1) / 256 ) ) then block
                                        end block
                                        elsif (( address ) >= 256 *( 1 )) then
                                        _LA_buffer1 [ ( address ) - 256 *( 1 ) ] = ( data )
                                        else
                                        _LA_buffer0 [ address ] = data
                                        end procedure

                                        and now could be compiled by JAL (see those double '' I mentioned
                                        above?). This multistep process is transparent and there are
                                        actually #line directives so JAL is able to track files and lines
                                        numbers properly. Unlike the original approach where JAL has to
                                        compile whole 35 Kbytes of source file (at least) eliminating
                                        not needed parts one by one here it only sees little piece of
                                        1Kbyte.

                                        Preprocessor is not the MUST - but in my experience when we try
                                        to create some generic and reconfigurable code - is very helpful.
                                        CPP is just one kind of preprocessor - one could even write his
                                        own - but it's not an easy job and preprocessor "language" better
                                        be standard also.

                                        Arcady
                                      • jsuijs
                                        Hi Arcady, Nice experiment! What I don t understand is why your large-array can be so much smaller than Matts one. I guess comments and long variable names
                                        Message 19 of 22 , Oct 10, 2010
                                        • 0 Attachment
                                          Hi Arcady,

                                          Nice experiment!

                                          What I don't understand is why 'your' large-array can be so much smaller than Matts one. I guess comments and long variable names largly contribute to this...
                                          The good thing about the JAL compiler is that it's fast. E.g. boostc takes more time to compile a 5-line program than JAL does by a memory-filling one.

                                          An other point to bridge from this experiment to an actual working situation (in addition to the double ') is preprocessor expansion on included files, since this is done by the compiler. And it should be able to handle all kind of text (like single quotes) in what jal considers comment.
                                          And although I agree with you that a standard preprocessor language would be best, the preprocessor implementation should be adapted to support jal syntax and not impose a limitation. I don't know if it is feasable to modify the C preprocessor to do so, or it needs to be rewritten...

                                          And out of curiosity: when I read your messages you seem to qualify most differences between jal and C as 'unfortunate'. So why did you choose JAL and not a c-compiler?

                                          Joep
                                        • Sebastien Lelong
                                          Hi guys, Beside large array libraries, there are also PWM libs for instance. For each available channel, a lib exist (so there are currently 10 libs + common
                                          Message 20 of 22 , Oct 11, 2010
                                          • 0 Attachment
                                            Hi guys,

                                            Beside large array libraries, there are also PWM libs for instance. For each
                                            available channel, a lib exist (so there are currently 10 libs + common
                                            lib). These libs are actually generated from a python template (Cheetah).
                                            This is obviously not directly usable, but al least limit duplication of
                                            code at developer's level. Anyway this would be a good candidate for
                                            preprocessing.

                                            Another candidate would be ADC library. adc_channels.jal is also generated
                                            from a python template (
                                            http://code.google.com/p/jallib/source/browse/trunk/tools/adc/adc_channels.jal.tmpl)
                                            which produces, in the end, more than 3000 loc. I don't know if this
                                            template could be replaced by a preprocessing step, as it uses many, many
                                            external data (pin information, adc group, etc...). Since I never used
                                            preprocessor (but know it can be useful), I don't know how much advanced it
                                            can be. My ADC template actually performs "for" loop, uses dictionaries,
                                            lists, assertions, ... organized as functions for readability. Is it out of
                                            preprocessor context ? My guess would be "no", but I wonder if it would be
                                            more readable...

                                            Cheers,
                                            Seb


                                            2010/10/11 jsuijs <jsuijs@...>

                                            >
                                            >
                                            > Hi Arcady,
                                            >
                                            > Nice experiment!
                                            >
                                            > What I don't understand is why 'your' large-array can be so much smaller
                                            > than Matts one. I guess comments and long variable names largly contribute
                                            > to this...
                                            > The good thing about the JAL compiler is that it's fast. E.g. boostc takes
                                            > more time to compile a 5-line program than JAL does by a memory-filling one.
                                            >
                                            > An other point to bridge from this experiment to an actual working
                                            > situation (in addition to the double ') is preprocessor expansion on
                                            > included files, since this is done by the compiler. And it should be able to
                                            > handle all kind of text (like single quotes) in what jal considers comment.
                                            > And although I agree with you that a standard preprocessor language would
                                            > be best, the preprocessor implementation should be adapted to support jal
                                            > syntax and not impose a limitation. I don't know if it is feasable to modify
                                            > the C preprocessor to do so, or it needs to be rewritten...
                                            >
                                            > And out of curiosity: when I read your messages you seem to qualify most
                                            > differences between jal and C as 'unfortunate'. So why did you choose JAL
                                            > and not a c-compiler?
                                            >
                                            > Joep
                                            >


                                            [Non-text portions of this message have been removed]
                                          • a_b_aldus
                                            ... It s simple - original LA code is 4 times repetition of same file where name large_array1 is replaced to large_array[2-4]. Each file now (30Kb) is
                                            Message 21 of 22 , Oct 11, 2010
                                            • 0 Attachment
                                              --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@...> wrote:
                                              > What I don't understand is why 'your' large-array can be so much smaller than Matts one. I guess comments and long variable names largly contribute to this...

                                              It's simple - original LA code is 4 times repetition of same file
                                              where name large_array1 is replaced to large_array[2-4]. Each file
                                              now (30Kb) is repetition of same code for array of 1, 2, 4 bytes.
                                              See - now it's down to 10Kb. Then there is some code repetition
                                              for arrays of 256+, 512+, 768+ and so far elements. Now we are
                                              down to my version of the code where everything is written just
                                              once. Resulting code (when all conditional complilation is done)
                                              is mostly the same - it is actually few VAR's and two functions,
                                              but in my case text should be written once and any changes I do
                                              in the algorithms would be immediately reflected in any use of the
                                              code w/o need to propogate changes into 4*3*7 places.

                                              > The good thing about the JAL compiler is that it's fast. E.g. boostc takes more time to compile a 5-line program than JAL does by a memory-filling one.

                                              And as the rule preprocessor would not change it - especially
                                              if it is Unix OS where pipeline is used for communication. But
                                              even Windows with temp files would not suffer much, if it's your
                                              concern.

                                              > An other point to bridge from this experiment to an actual working situation (in addition to the double ') is preprocessor expansion on included files, since this is done by the compiler. And it should be able to handle all kind of text (like single quotes) in what jal considers comment.

                                              This could be achieved by taking sources of CPP (freely available)
                                              and doing some simple modifications to be conformant with JAL.

                                              > And although I agree with you that a standard preprocessor language would be best, the preprocessor implementation should be adapted to support jal syntax and not impose a limitation. I don't know if it is feasable to modify the C preprocessor to do so, or it needs to be rewritten...

                                              Easily.

                                              > And out of curiosity: when I read your messages you seem to qualify most differences between jal and C as 'unfortunate'. So why did you choose JAL and not a c-compiler?

                                              I use both - from my point of view JAL has a different gamefield
                                              (and has some very interesting features indeed). My experience
                                              says that C would live, and any new language better to borrow
                                              the best from the C (it does not have to became C - but really
                                              to look like C is very convinient from "infrastructure" point of
                                              view - there is lot of utils understanding syntax of C - editors,
                                              code browsers, formatters). So - long life to both!

                                              Arcady
                                            • a_b_aldus
                                              ... It is definitely not the realm of C preprocessor - there are no loops or external lookups . I would say that you already created kind of preprocessor -
                                              Message 22 of 22 , Oct 11, 2010
                                              • 0 Attachment
                                                --- In jallist@yahoogroups.com, Sebastien Lelong <sebastien.lelong@...> wrote:

                                                > which produces, in the end, more than 3000 loc. I don't know if this
                                                > template could be replaced by a preprocessing step, as it uses many, many
                                                > external data (pin information, adc group, etc...). Since I never used
                                                > preprocessor (but know it can be useful), I don't know how much advanced it
                                                > can be. My ADC template actually performs "for" loop, uses dictionaries,
                                                > lists, assertions, ... organized as functions for readability. Is it out of
                                                > preprocessor context ? My guess would be "no", but I wonder if it would be
                                                > more readable...

                                                It is definitely not the realm of C preprocessor - there are no
                                                loops or external "lookups". I would say that you already created
                                                kind of "preprocessor" - not so straightforward for anybody to
                                                use but something. It's possible (may be) to "rewrite" the templates
                                                you have to allow this generation on fly but it would also require
                                                to rewrite processors definition files and this is not so
                                                reasonable.

                                                Arcady
                                              Your message has been successfully submitted and would be delivered to recipients shortly.