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

Re: [Jal_developers] Patch for jal

Expand Messages
  • 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 1 of 13 , Oct 29, 2005
      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 2 of 13 , Nov 3, 2005
        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 3 of 13 , Nov 3, 2005
          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 4 of 13 , Nov 7, 2005
            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 5 of 13 , Nov 7, 2005
              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 6 of 13 , Nov 7, 2005
                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 7 of 13 , Nov 7, 2005
                  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 8 of 13 , Nov 7, 2005
                    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 9 of 13 , Nov 7, 2005
                      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 10 of 13 , Nov 8, 2005
                        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 11 of 13 , Nov 8, 2005
                          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 12 of 13 , Nov 9, 2005
                            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.