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

Re: can I use JAL on a Raspberry ?

Expand Messages
  • jsuijs
    Hi Wouter, The first attempt (called JAT - Just Another Translator) was based on an antlr grammar definition and provided a flexible way to write code in JAL
    Message 1 of 20 , Jul 31, 2012
      Hi Wouter,

      The first attempt (called JAT - Just Another Translator) was based on an antlr grammar definition and provided a flexible way to write code in JAL that interacts with C (library) functions. This proved to work okay, but was not completely finished (bit fields amongst others, iirc). Working targets are atmel (arduino), arm and pic32.
      However, proceeding that path would not provide a 100% compatible system, so I decided to redirect my effort to investigate the option of creating a backend for the current compiler.
      I think this will be feasible, but the result would be less flexible (since there is no way to pass identifiers to the C compiler). An other limitation is the 16 bit range of the compiler output, which makes it harder to support 32 bit hardware.
      Note that Kyle provided a lot of support on this and also mentioned there might be options to resolve at least some of the issues.

      Looking back, I'd probably vote not to pursue the compiler backend-to-C option due to the limited flexibility and effort required for libraries for each port. Creating an emulator, or a virtual machine + corresponding backend might be a better option if you want 100% compatibility.

      As for JAT: I still think this is a nice and powerful tool for those that love JAL syntax and want to use it on more powerful platforms. The main question to answer is what the consequences are if a dialect of JAL is introduced...

      Joep


      --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@...> wrote:
      >
      > > I worked on JAL-to-C translation about 2 years ago, which would allow to
      > > run compiled JAL code on much more platforms, including 32 bits arm. The
      > > proof of concept was succesful, but there were remaining issues which
      > > made me decide to abandon the project.
      >
      > Which were the remaining issues?
      >
      > --
      >
      > Wouter van Ooijen
      >
      > -- -------------------------------------------
      > Van Ooijen Technische Informatica: www.voti.nl
      > consultancy, development, PICmicro products
      > docent Hogeschool van Utrecht: www.voti.nl/hvu
      > C++ on uC blog: http://www.voti.nl/erblog
      >
    • jsuijs
      Hi Matt, ... It is next to impossible to have 100% compatibility on the antlr path. This means the most desirable option is not available. This still leaves
      Message 2 of 20 , Aug 1, 2012
        Hi Matt,

        --- In jallist@yahoogroups.com, "Matthew Schinkel" <mattschinkel@...> wrote:
        >
        > One issue I can think of is that it would require current JAL to run
        > the same without modifications. I think Joep said that would be
        > difficult to have a 100% match. Is this true? If this is the case,
        > we have no choice.
        It is next to impossible to have 100% compatibility on the antlr path. This means the most desirable option is not available. This still leaves a choice IMHO: stick to the 16f/18f devices with JAL, or have a JAL dialect that runs on about any processor with a C compiler available...

        > I do hope someone can begin development again. I think some of the
        > questions about compatibility had discouraged Joep and others
        > working on it, which I regret.
        It only makes sense to continue when one chooses to have a JAL dialect, which you say is not an option ('no choice')...

        > If I knew C and Antlr (http://www.antlr.org/) I would assist. I did
        > try to look into it but it didn't go so well due my lack of Antlr C
        > language documentation. Maybe Antlr JAVA would be a better fit since
        > there is a lot more documentation.
        You're right: antlr integrates better with java than C and there is much more documentation available. This does still surface when you try to debug the grammar file, but in general, the C code for JAT to interface to anltr is up and running. It shouldn't be too dificult to port this to java though. But bear in mind it would add an other language to the working set of the developer (next to antlr grammar, jal and C).

        Joep
      • a_b_aldus
        ... Why such dialect should be introduced? Except probably to fix JAL grammar problems (there are many in some obscure corners of the language - due to
        Message 3 of 20 , Aug 1, 2012
          --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@...> wrote:
          > As for JAT: I still think this is a nice and powerful tool for those that love JAL syntax and want to use it on more powerful platforms. The main question to answer is what the consequences are if a dialect of JAL is introduced...

          Why such dialect should be introduced? Except probably to fix JAL
          grammar problems (there are many in some obscure corners of the
          language - due to original lack of clear grammar description) as
          well as lexer problems (lexical structure of include statement is
          different form one of mainstream JAL and structure of asm statement
          is again different). But asm code has no meaning outside of PIC
          target as well as most of pragmas that are used to configure the
          PIC.

          Generally speaking it is not hard to write manual lexer/parser
          that would accept JAL - problem is semantic code. As to 'strange'
          JAL types (like byte*5) - those could be implemented using lib
          calls for all arithmetic operations, unlike the simple ones that
          could be mapped to native types.

          Arcady

          >
          > Joep
          >
          >
          > --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@> wrote:
          > >
          > > > I worked on JAL-to-C translation about 2 years ago, which would allow to
          > > > run compiled JAL code on much more platforms, including 32 bits arm. The
          > > > proof of concept was succesful, but there were remaining issues which
          > > > made me decide to abandon the project.
          > >
          > > Which were the remaining issues?
          > >
          > > --
          > >
          > > Wouter van Ooijen
          > >
          > > -- -------------------------------------------
          > > Van Ooijen Technische Informatica: www.voti.nl
          > > consultancy, development, PICmicro products
          > > docent Hogeschool van Utrecht: www.voti.nl/hvu
          > > C++ on uC blog: http://www.voti.nl/erblog
          > >
          >
        • jsuijs
          Hi Arcady, I use dialect to refer to slightly different behavior at specific points. For example an in/out variable iin jat is implemented by reference, so
          Message 4 of 20 , Aug 1, 2012
            Hi Arcady,

            I use 'dialect' to refer to slightly different behavior at specific points.
            For example an in/out variable iin jat is implemented by reference, so any value assigned in the procedure is visible at the original var location, while current jal only updates it upon return from the procedure.
            Iirc there were differences in handling array paramteters too, but can't remeber what they are.


            --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
            >
            > Generally speaking it is not hard to write manual lexer/parser
            > that would accept JAL - problem is semantic code. As to 'strange'
            > JAL types (like byte*5) - those could be implemented using lib
            > calls for all arithmetic operations, unlike the simple ones that
            > could be mapped to native types.

            It took my quite some time to get it up and running, but this might be due to my limited experience in this area of software development. Judging from wat you have written on this list, you might be the perfect man for the job...

            Joep
          • Wouter van Ooijen
            ... I dunno how the semantics of the current Jal are defined. My original Jal *behaved* that way, but the *definition* allowed for both implementations (either
            Message 5 of 20 , Aug 2, 2012
              > For example an in/out variable iin jat is implemented by reference, so
              > any value assigned in the procedure is visible at the original var
              > location, while current jal only updates it upon return from the procedure.
              > Iirc there were differences in handling array paramteters too, but can't
              > remeber what they are.

              I dunno how the semantics of the current Jal are defined. My original
              Jal *behaved* that way, but the *definition* allowed for both
              implementations (either reference, or copy-on copy_out).

              Don't confuse an implementation with the definition, even when there is
              only one implementation :)

              --

              Wouter van Ooijen

              -- -------------------------------------------
              Van Ooijen Technische Informatica: www.voti.nl
              consultancy, development, PICmicro products
              docent Hogeschool van Utrecht: www.voti.nl/hvu
              C++ on uC blog: http://www.voti.nl/erblog
            • jsuijs
              Hi Wouter, ... Good point! I considered the current JAL compiler behaviour as a reference implementation, and so do others when the aim at recompile code
              Message 6 of 20 , Aug 2, 2012
                Hi Wouter,

                --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@...> wrote:
                > Don't confuse an implementation with the definition, even when there
                > is only one implementation :)

                Good point! I considered the current JAL compiler behaviour as a reference implementation, and so do others when the aim at 'recompile code without any change'.
                The question is what is considered the right definition. JAT already covers a lot which was described in the v2 compiler language definition. It is however limited in the variables supported (to type that have an equivalent in C, iirc) and no stuctures (which did not exist in JAL at the time.

                So this might be an interesting project. To bad I have too many of those at hand ;)

                Joep
              • vasi
                It would be great if Kyle begin writing a Jalv2 compiler for, let s say, ATmega328P - then it would be easy to extend the support for ATmega168P, ATmega644P,
                Message 7 of 20 , Aug 2, 2012
                  It would be great if Kyle begin writing a Jalv2 compiler for, let's say, ATmega328P - then it would be "easy" to extend the support for ATmega168P, ATmega644P, ATmega1284P... and I think it can be enough for start (or even the end). These are faster microcontrollers than PIC18F...
                  It will tremendously help in rising the JAL popularity and who knows, maybe someone will start writing one also for AVR32 and/or ARM.

                  One step at the time...

                  --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@...> wrote:
                  >
                  > Hi Wouter,
                  >
                  > --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@> wrote:
                  > > Don't confuse an implementation with the definition, even when there
                  > > is only one implementation :)
                  >
                  > Good point! I considered the current JAL compiler behaviour as a reference implementation, and so do others when the aim at 'recompile code without any change'.
                  > The question is what is considered the right definition. JAT already covers a lot which was described in the v2 compiler language definition. It is however limited in the variables supported (to type that have an equivalent in C, iirc) and no stuctures (which did not exist in JAL at the time.
                  >
                  > So this might be an interesting project. To bad I have too many of those at hand ;)
                  >
                  > Joep
                  >
                • vasi
                  In support for this proposal, Great Cow Basic, and open source Basic compiler come with support for both PIC and AVR microcontrollers:
                  Message 8 of 20 , Aug 3, 2012
                    In support for this proposal, Great Cow Basic, and open source Basic compiler come with support for both PIC and AVR microcontrollers:
                    http://gcbasic.sourceforge.net/


                    --- In jallist@yahoogroups.com, "vasi" <funlw65@...> wrote:
                    >
                    > It would be great if Kyle begin writing a Jalv2 compiler for, let's say, ATmega328P - then it would be "easy" to extend the support for ATmega168P, ATmega644P, ATmega1284P... and I think it can be enough for start (or even the end). These are faster microcontrollers than PIC18F...
                    > It will tremendously help in rising the JAL popularity and who knows, maybe someone will start writing one also for AVR32 and/or ARM.
                    >
                    > One step at the time...
                    >
                    > --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@> wrote:
                    > >
                    > > Hi Wouter,
                    > >
                    > > --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@> wrote:
                    > > > Don't confuse an implementation with the definition, even when there
                    > > > is only one implementation :)
                    > >
                    > > Good point! I considered the current JAL compiler behaviour as a reference implementation, and so do others when the aim at 'recompile code without any change'.
                    > > The question is what is considered the right definition. JAT already covers a lot which was described in the v2 compiler language definition. It is however limited in the variables supported (to type that have an equivalent in C, iirc) and no stuctures (which did not exist in JAL at the time.
                    > >
                    > > So this might be an interesting project. To bad I have too many of those at hand ;)
                    > >
                    > > Joep
                    > >
                    >
                  • zz
                    Greetings, ... Just for fun I downloaded & am looking at the AVR instruction set. Wow! It makes the PIC instructions look almost sane.
                    Message 9 of 20 , Aug 3, 2012
                      Greetings,

                      --- In jallist@yahoogroups.com, "vasi" <funlw65@...> wrote:
                      >
                      > It would be great if Kyle begin writing a Jalv2 compiler for, let's say, ATmega328P - then it would be "easy" to extend the support for ATmega168P, ATmega644P, ATmega1284P... and I think it can be enough for start (or even the end). These are faster microcontrollers than PIC18F...
                      > It will tremendously help in rising the JAL popularity and who knows, maybe someone will start writing one also for AVR32 and/or ARM.

                      Just for fun I downloaded & am looking at the AVR instruction set. Wow! It makes the PIC instructions look almost sane.

                      >
                      > One step at the time...
                      >
                      > --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@> wrote:
                      > >
                      > > Hi Wouter,
                      > >
                      > > --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@> wrote:
                      > > > Don't confuse an implementation with the definition, even when there
                      > > > is only one implementation :)
                      > >
                      > > Good point! I considered the current JAL compiler behaviour as a reference implementation, and so do others when the aim at 'recompile code without any change'.
                      > > The question is what is considered the right definition. JAT already covers a lot which was described in the v2 compiler language definition. It is however limited in the variables supported (to type that have an equivalent in C, iirc) and no stuctures (which did not exist in JAL at the time.
                      > >
                      > > So this might be an interesting project. To bad I have too many of those at hand ;)
                      > >
                      > > Joep
                      > >
                      >
                    • jsuijs
                      If anyone is interested in JAT, see http://jallib.googlecode.com/svn/trunk/jat/source/Implementation%20of%20JAT.docx This gives info on the implementation and
                      Message 10 of 20 , Aug 4, 2012
                        If anyone is interested in JAT, see
                        http://jallib.googlecode.com/svn/trunk/jat/source/Implementation%20of%20JAT.docx

                        This gives info on the implementation and status.

                        The brief status:
                        - JAT is case-sensitive
                        - Arrays are not fully implemented. When this is done, JAT is a pretty useful tool.
                        - JAL has many powerful variable options, like bit fields and byte*n sized vars. They are not supported yet.

                        Support of variable options, including the required C lib functions for all supported sizes is the next major task to change JAT from a pretty useful tool to an 'almost JAL compatible' tool. If someone intends to continue JAT development, this would be a good place to start. And in this case, I offer to finish the array implementation.

                        The arduino/atmel support available is just to show it can be done. The real potential of JAT is at faster microcontrollers. ARM processors are only slightly more expensive and offer significant more RAM, FLASH and speed which can be utilized at almost native speed with JAT. I wonder what the speed of the code on the Raspberry pi would be when run via JAT...

                        Joep


                        --- In jallist@yahoogroups.com, "jsuijs" <jsuijs@...> wrote:
                        >
                        > Hi Wouter,
                        >
                        > --- In jallist@yahoogroups.com, Wouter van Ooijen <wouter@> wrote:
                        > > Don't confuse an implementation with the definition, even when there
                        > > is only one implementation :)
                        >
                        > Good point! I considered the current JAL compiler behaviour as a reference implementation, and so do others when the aim at 'recompile code without any change'.
                        > The question is what is considered the right definition. JAT already covers a lot which was described in the v2 compiler language definition. It is however limited in the variables supported (to type that have an equivalent in C, iirc) and no stuctures (which did not exist in JAL at the time.
                        >
                        > So this might be an interesting project. To bad I have too many of those at hand ;)
                        >
                        > Joep
                        >
                      • Vasile
                        ... oh my God! walking LEDs on ARM.... awesome! does Robbert like programming or is just a family business where his father is the boss? best wishes, Vasile
                        Message 11 of 20 , Aug 8, 2012
                          --- In jallist@yahoogroups.com, Stef Mientki <stef.mientki@...> wrote:
                          >
                          >
                          > http://www.student.tue.nl/W/r.mientki/raspberry2.htm (large)
                          >
                          > http://www.student.tue.nl/W/r.mientki/running_jal.html
                          >
                          > http://www.student.tue.nl/W/r.mientki/running_python.html
                          >

                          oh my God! walking LEDs on ARM....
                          awesome!

                          does Robbert like programming or is just a family business where his father is the boss?

                          best wishes,
                          Vasile
                        Your message has been successfully submitted and would be delivered to recipients shortly.