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

Patch for jal

Expand Messages
  • Marco Pantaleoni
    Hi, I ve added support to jal for cpp-like preprocessors (cpp, gpp, ...). This essentialy allows to write macros using #define (and correctly handle line
    Message 1 of 13 , Oct 27, 2005
    • 0 Attachment
      Hi,
      I've added support to jal for cpp-like preprocessors (cpp, gpp, ...).
      This essentialy allows to write macros using #define (and correctly handle
      line numbers when using #include). gpp also has some extensions to cpp that
      can be useful with jal (like user-definable comment syntax, immediate macro
      evaluation, ...).
      I attach the unified diff patch agains the cvs version of jal.
      I hope that this could be useful to someone else beside me.

      Cheers,
      Marco

      --
      Marco Pantaleoni

      elastiC language developer
      http://www.elasticworld.org
    • Javier Martinez
      Hi Marco, Can you post a brief example in JAL? I ll upload changes to jal.sf.net CVS repository. Regards, Javi.
      Message 2 of 13 , Oct 29, 2005
      • 0 Attachment
        Hi Marco,

        Can you post a brief example in JAL?

        I'll upload changes to jal.sf.net CVS repository.


        Regards,
        Javi.



        On vie, 2005-10-28 at 00:45 +0200, Marco Pantaleoni wrote:
        > Hi,
        > I've added support to jal for cpp-like preprocessors (cpp, gpp, ...).
        > This essentialy allows to write macros using #define (and correctly handle
        > line numbers when using #include). gpp also has some extensions to cpp that
        > can be useful with jal (like user-definable comment syntax, immediate macro
        > evaluation, ...).
        > I attach the unified diff patch agains the cvs version of jal.
        > I hope that this could be useful to someone else beside me.
        >
        > Cheers,
        > Marco
        >
      • Marco Pantaleoni
        ... Hi Javier, I apologize for the late answer, but I ve been out of town. ... of course. The main use of preprocessor support in jal is to write macros, short
        Message 3 of 13 , Nov 3, 2005
        • 0 Attachment
          On Saturday 29 October 2005 17:35, Javier Martinez wrote:
          > Hi Marco,

          Hi Javier,
          I apologize for the late answer, but I've been out of town.

          >
          > Can you post a brief example in JAL?

          of course.
          The main use of preprocessor support in jal is to write macros, short
          sequences of statements used quite often, but for which a function call would
          be overkill (or too expensive in some cases). Macros should be used with
          caution and moderation though, because it's easy to use them improperly or to
          get burned with unforeseen "side effects" of expansion.
          A short, and silly, example could be:

          silly-example.jal
          ------------------------------------------------------------------------

          include f877_4
          include jlib

          pragma target fuses 0x3F32

          disable_a_d_functions

          var bit LED1 is pin_a0
          var bit LED2 is pin_a1

          pin_a0_direction = output
          pin_a1_direction = output

          #define CYCLE_1(ms) \
          delay_10ms( (ms) ) \
          LED1 = high \
          LED2 = low

          #define CYCLE_2(ms) \
          delay_10ms( (ms) ) \
          LED1 = low \
          LED2 = high

          forever loop
          CYCLE_1(25)

          CYCLE_2(25)
          end loop


          To use this example, we have to call the preprocessor before jal.
          For example:

          $ cpp silly-example.jal silly-example-expanded.jal
          $ jal silly-example-expanded.jal

          This first command will process "silly-example.jal" emitting its output in
          "silly-example-expanded.jal". Then with the second command we simply compile
          the generated file.

          If you like, I'll add a command line switch to jal to invoke automatically the
          preprocessor, thus avoiding the two separate commands shown above.

          Cheers,
          Marco

          --
          Marco Pantaleoni

          elastiC language developer
          http://www.elasticworld.org
        • Marco Pantaleoni
          ... I ve added that switch. Now if you run jal with the -P switch, it will invoke cpp for you. Compiling the example of the previous message would become: $
          Message 4 of 13 , Nov 3, 2005
          • 0 Attachment
            On Thursday 03 November 2005 16:34, Marco Pantaleoni wrote:
            >
            > If you like, I'll add a command line switch to jal to invoke automatically
            > the preprocessor, thus avoiding the two separate commands shown above.

            I've added that switch. Now if you run jal with the "-P" switch, it will
            invoke cpp for you.
            Compiling the example of the previous message would become:

            $ jal -P silly-example.jal

            (jal will call cpp handling automatically the temporary file creation and
            removal).

            You can also specify a different "cpp" passing a command string to -P, as in:

            $ jal -P/usr/local/bin/cpp silly-example.jal

            you can pass complex commands quoting with simple or double quotes the
            command:

            $ jal -P'/usr/local/bin/cpp -funny' silly-example.jal

            I can't check if CVS has been updated recently (it goes in time-out right
            now), so I'm providing a patch against the CVS version without my previous
            patch. In other words, this patch supersedes the previous one.

            Cheers,
            Marco

            --
            Marco Pantaleoni

            elastiC language developer
            http://www.elasticworld.org
          • Javier Martinez
            Hi Marco, Sorry, I ve been busy. ;) Just 2 questions. The main one: seems that needs an external C preprocessor, isn t it? This will be useless for 95% of
            Message 5 of 13 , Nov 7, 2005
            • 0 Attachment
              Hi Marco,

              Sorry, I've been busy. ;)

              Just 2 questions.

              The main one: seems that needs an external C preprocessor, isn't it?
              This will be useless for 95% of JAL users, and this will give us a lot
              of problems about this.

              The second one, just a thought: looks like C too much, is there a way
              to "JALify" it? I'm thinking in something like a procedure/function
              syntax: "macro ( ) is ... end macro".


              Tell me what do you think prior to do anything. Otherwise it's fine.


              Regards,
              Javi.


              On jue, 2005-11-03 at 17:40 +0100, Marco Pantaleoni wrote:
              > On Thursday 03 November 2005 16:34, Marco Pantaleoni wrote:
              > >
              > > If you like, I'll add a command line switch to jal to invoke automatically
              > > the preprocessor, thus avoiding the two separate commands shown above.
              >
              > I've added that switch. Now if you run jal with the "-P" switch, it will
              > invoke cpp for you.
              > Compiling the example of the previous message would become:
              >
              > $ jal -P silly-example.jal
              >
              > (jal will call cpp handling automatically the temporary file creation and
              > removal).
              >
              > You can also specify a different "cpp" passing a command string to -P, as in:
              >
              > $ jal -P/usr/local/bin/cpp silly-example.jal
              >
              > you can pass complex commands quoting with simple or double quotes the
              > command:
              >
              > $ jal -P'/usr/local/bin/cpp -funny' silly-example.jal
              >
              > I can't check if CVS has been updated recently (it goes in time-out right
              > now), so I'm providing a patch against the CVS version without my previous
              > patch. In other words, this patch supersedes the previous one.
              >
              > Cheers,
              > Marco
              >
            • Marco Pantaleoni
              ... Yes, but if someone doesn t need it, he can just ignore it. One possible solution could be to selective enable the preprocessor support when running the
              Message 6 of 13 , Nov 7, 2005
              • 0 Attachment
                On Monday 07 November 2005 17:41, Javier Martinez wrote:
                > Hi Marco,
                >
                > Sorry, I've been busy. ;)
                >
                > Just 2 questions.
                >
                > The main one: seems that needs an external C preprocessor, isn't it?
                > This will be useless for 95% of JAL users, and this will give us a lot
                > of problems about this.

                Yes, but if someone doesn't need it, he can just ignore it.

                One possible solution could be to selective enable the preprocessor support
                when running the "configure" script, if called with an "--enable-cpp" switch.
                What do you think about this?

                > The second one, just a thought: looks like C too much, is there a way
                > to "JALify" it? I'm thinking in something like a procedure/function
                > syntax: "macro ( ) is ... end macro".

                This of course would be the best solution, but I suspect it would require
                non-trivial changes to the parser. If jal could parse from a string (starting
                from an arbitrary point in the original file, and resuming to the same point
                afterwards), it would be quite easy to do, but I doubt it has this
                functionality.
                I'll try to think if I can envision a solution, but someone with a deeper
                understanding than mine of the jal parser could give better indications.

                Ciao,
                Marco

                --
                Marco Pantaleoni

                elastiC language developer
                http://www.elasticworld.org
              • Javier Martinez
                Hi Marco, ... Yes, but what about sharing code? These macro functions will make JAL other language (JAL-cpp vs JAL), that is you ll not able to share code
                Message 7 of 13 , Nov 7, 2005
                • 0 Attachment
                  Hi Marco,

                  > Yes, but if someone doesn't need it, he can just ignore it.
                  >
                  > One possible solution could be to selective enable the preprocessor support
                  > when running the "configure" script, if called with an "--enable-cpp" switch.
                  > What do you think about this?

                  Yes, but what about sharing code? These macro functions will make JAL
                  "other" language (JAL-cpp vs JAL), that is you'll not able to share code
                  with other "not-cpp" jallians. Should be nice to find a solution
                  affordable for all, rather than for a few ones.

                  And yes, the best way to enable it is in configure script.




                  > > The second one, just a thought: looks like C too much, is there a way
                  > > to "JALify" it? I'm thinking in something like a procedure/function
                  > > syntax: "macro ( ) is ... end macro".
                  >
                  > This of course would be the best solution, but I suspect it would require
                  > non-trivial changes to the parser. If jal could parse from a string (starting
                  > from an arbitrary point in the original file, and resuming to the same itpoint
                  > afterwards), it would be quite easy to do, but I doubt it has this
                  > functionality.
                  > I'll try to think if I can envision a solution, but someone with a deeper
                  > understanding than mine of the jal parser could give better indications.
                  >
                  > Ciao,
                  > Marco
                  >

                  Let's go with my first question, and then if all it's ok will find
                  a solution here.



                  Regards,
                  Javi.
                • Marco Pantaleoni
                  ... You are right, it would impede code sharing. I think of this feature as a sharp knife , to be used exclusively when unavoidable, but I understand that
                  Message 8 of 13 , Nov 7, 2005
                  • 0 Attachment
                    On Monday 07 November 2005 18:14, Javier Martinez wrote:
                    > Hi Marco,
                    >
                    > > Yes, but if someone doesn't need it, he can just ignore it.
                    > >
                    > > One possible solution could be to selective enable the preprocessor
                    > > support when running the "configure" script, if called with an
                    > > "--enable-cpp" switch. What do you think about this?
                    >
                    > Yes, but what about sharing code? These macro functions will make JAL
                    > "other" language (JAL-cpp vs JAL), that is you'll not able to share code
                    > with other "not-cpp" jallians. Should be nice to find a solution
                    > affordable for all, rather than for a few ones.
                    >
                    > And yes, the best way to enable it is in configure script.

                    You are right, it would impede code sharing. I think of this feature as a
                    "sharp knife", to be used exclusively when unavoidable, but I understand that
                    once users have access to a tool they tend to use it :-)

                    > > > The second one, just a thought: looks like C too much, is there a
                    > > > way to "JALify" it? I'm thinking in something like a procedure/function
                    > > > syntax: "macro ( ) is ... end macro".
                    > >
                    > > This of course would be the best solution, but I suspect it would require
                    > > non-trivial changes to the parser. If jal could parse from a string
                    > > (starting from an arbitrary point in the original file, and resuming to
                    > > the same itpoint afterwards), it would be quite easy to do, but I doubt
                    > > it has this functionality.
                    > > I'll try to think if I can envision a solution, but someone with a deeper
                    > > understanding than mine of the jal parser could give better indications.
                    > >
                    > > Ciao,
                    > > Marco
                    >
                    > Let's go with my first question, and then if all it's ok will find
                    > a solution here.

                    I'd go for the JAL-style solution, but I'd need some help here.

                    Later,
                    Marco

                    --
                    Marco Pantaleoni

                    elastiC language developer
                    http://www.elasticworld.org
                  • Stef Mientki
                    ... hello Marco, Javi, As a non-C-programmer, I cann t understand the full extend / consequences of this C-isch macro implementation, but here a few remarks:
                    Message 9 of 13 , Nov 7, 2005
                    • 0 Attachment
                      Javier Martinez wrote:

                      >Hi Marco,
                      >
                      >
                      >
                      >>Yes, but if someone doesn't need it, he can just ignore it.
                      >>
                      >>One possible solution could be to selective enable the preprocessor support
                      >>when running the "configure" script, if called with an "--enable-cpp" switch.
                      >>What do you think about this?
                      >>
                      >>
                      >
                      > Yes, but what about sharing code? These macro functions will make JAL
                      >"other" language (JAL-cpp vs JAL), that is you'll not able to share code
                      >with other "not-cpp" jallians. Should be nice to find a solution
                      >affordable for all, rather than for a few ones.
                      >
                      >
                      >
                      >
                      hello Marco, Javi,

                      As a non-C-programmer, I cann't understand the full extend /
                      consequences of this C-isch macro implementation,
                      but here a few remarks:

                      1. Macro's can never extend or change the real functionality /
                      performance of the compiler. This would imply that a macro-machine
                      should always or best be implemented as a pre-processor.

                      2. As I showed in JALcc, it's very well possible to create a
                      pre-processor which is capable of perfoming complex macro actions, while
                      still holding 100% compatibility with "standard JAL", see
                      http://oase.uci.kun.nl/~mientki/pic/jalcc/help/jalcc_macro.html
                      <http://oase.uci.kun.nl/%7Emientki/pic/jalcc/help/jalcc_macro.html>
                      If you look at the block "Inline Macro,IO-pin, about the end of the
                      first page, you can see how this is implemented.

                      3. The mentioned page describes only the build in macros in JALcc, I've
                      build in user definenable macros, but as I'm not satisfied about them,
                      they are not made public.

                      4. I'ld love to come together to get a standard definition of macros
                      (maybe even fully compatible with mchip-macros), which then can be
                      implemented in different pre-processors.

                      just my 2-euro-cents

                      cheers,
                      Stef
                    • Marco Pantaleoni
                      ... I agree, but while on unix-like systems a pre-processor is (almost) always present, on other systems (windows), it is not. I m not interested in windows
                      Message 10 of 13 , Nov 7, 2005
                      • 0 Attachment
                        On Monday 07 November 2005 19:40, Stef Mientki wrote:
                        >
                        > hello Marco, Javi,
                        >
                        > As a non-C-programmer, I cann't understand the full extend /
                        > consequences of this C-isch macro implementation,
                        > but here a few remarks:
                        >
                        > 1. Macro's can never extend or change the real functionality /
                        > performance of the compiler. This would imply that a macro-machine
                        > should always or best be implemented as a pre-processor.

                        I agree, but while on unix-like systems a pre-processor is (almost) always
                        present, on other systems (windows), it is not. I'm not interested in windows
                        personally, but someone else could be, and maybe they don't want to install a
                        third-party program.

                        >
                        > 2. As I showed in JALcc, it's very well possible to create a
                        > pre-processor which is capable of perfoming complex macro actions, while
                        > still holding 100% compatibility with "standard JAL", see
                        > http://oase.uci.kun.nl/~mientki/pic/jalcc/help/jalcc_macro.html
                        > <http://oase.uci.kun.nl/%7Emientki/pic/jalcc/help/jalcc_macro.html>
                        > If you look at the block "Inline Macro,IO-pin, about the end of the
                        > first page, you can see how this is implemented.

                        my extension to JAL is 100% compatible with "standard JAL" too, but the
                        problem is the other way round: code that uses macros is not understood by
                        plain JAL.

                        I've a couple of ideas regarding direct implementation of macros in JAL, I'll
                        see in the next few days if they are viable.

                        Cheers,
                        Marco

                        --
                        Marco Pantaleoni

                        elastiC language developer
                        http://www.elasticworld.org
                      • Javier Martinez
                        Hi all, ... Marco, you hit in the bulls eye. Ask in the jallist how many of them have a C compiler to build latest JAL sources .... ... and now think that
                        Message 11 of 13 , Nov 8, 2005
                        • 0 Attachment
                          Hi all,

                          > > 1. Macro's can never extend or change the real functionality /
                          > > performance of the compiler. This would imply that a macro-machine
                          > > should always or best be implemented as a pre-processor.
                          >
                          > I agree, but while on unix-like systems a pre-processor is (almost) always
                          > present, on other systems (windows), it is not. I'm not interested in windows
                          > personally, but someone else could be, and maybe they don't want to install a
                          > third-party program.

                          Marco, you hit in the bulls eye. Ask in the jallist how many of them
                          have a C compiler to build latest JAL sources ....

                          ... and now think that we're asking them to have a C preprocessor to
                          daily work with JAL.

                          As a starting position (just begin to do something), we can place
                          your code as a patch of latest sources. If I recall well, SF.net have a
                          special entry for this purposes.


                          Waiting your comments.



                          Regards,
                          Javi.
                        • Marco Pantaleoni
                          ... Yes, I understand. ... This sounds great! Thanks. In the meantime I ll try to come to a more integrated solution. I ll keep you posted. Cheers, Marco --
                          Message 12 of 13 , Nov 8, 2005
                          • 0 Attachment
                            On Tuesday 08 November 2005 17:53, Javier Martinez wrote:
                            > Hi all,
                            >
                            > > > 1. Macro's can never extend or change the real functionality /
                            > > > performance of the compiler. This would imply that a macro-machine
                            > > > should always or best be implemented as a pre-processor.
                            > >
                            > > I agree, but while on unix-like systems a pre-processor is (almost)
                            > > always present, on other systems (windows), it is not. I'm not interested
                            > > in windows personally, but someone else could be, and maybe they don't
                            > > want to install a third-party program.
                            >
                            > Marco, you hit in the bulls eye. Ask in the jallist how many of them
                            > have a C compiler to build latest JAL sources ....
                            >
                            > ... and now think that we're asking them to have a C preprocessor to
                            > daily work with JAL.

                            Yes, I understand.

                            > As a starting position (just begin to do something), we can place
                            > your code as a patch of latest sources. If I recall well, SF.net have a
                            > special entry for this purposes.

                            This sounds great! Thanks.

                            In the meantime I'll try to come to a more integrated solution.
                            I'll keep you posted.

                            Cheers,
                            Marco

                            --
                            Marco Pantaleoni

                            elastiC language developer
                            http://www.elasticworld.org
                          • Javier Martinez
                            Hi all, Available patches in jal.sf.net: ID Summary 1352435 10Fxxx support 1352433 Preprocessor support 1118846 JAL 16F648 Extensions Regards, Javi.
                            Message 13 of 13 , Nov 9, 2005
                            • 0 Attachment
                              Hi all,

                              Available patches in jal.sf.net:

                              ID Summary
                              1352435 10Fxxx support
                              1352433 Preprocessor support
                              1118846 JAL 16F648 Extensions



                              Regards,
                              Javi.
                            Your message has been successfully submitted and would be delivered to recipients shortly.