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

Re: [Jal_developers] question about get/put variable overloading.

Expand Messages
  • Stef Mientki
    ... Sorry no answer, but if I understand you well ... do you have an alternative JAL compiler, with syntax equal to PBasic ? Stef Mientki
    Message 1 of 9 , Apr 8, 2005
    • 0 Attachment
      scx31114 wrote:

      >Please comment it shortly.
      >
      >
      Sorry no answer, but if I understand you well ...
      do you have an alternative JAL compiler,
      with syntax equal to PBasic ?

      Stef Mientki
    • nisma@gmx.net
      ... I have a small compiler (less then 500 lines of source +rtl ) that accept XML (flowchart), PBasic and syntax similar to Jal generating asm files as result.
      Message 2 of 9 , Apr 8, 2005
      • 0 Attachment
        >
        > >Please comment it shortly.
        > >
        > >
        > Sorry no answer, but if I understand you well ...
        > do you have an alternative JAL compiler,
        > with syntax equal to PBasic ?
        I have a small compiler (less then 500 lines of source +rtl ) that accept
        XML (flowchart), PBasic and syntax similar to Jal generating asm files as
        result.
        The compiler can invoke gpasm or other assemblers in order to produce a hex
        file. Principal differences to Jal: string support, no buildin assembler and
        simulator, no support for assertions and the subscript operator is a dot
        instead of the colon. All the syntax can be mixed.
        Currently i modify the syntax in order to be compatible with jal and adding
        some class/module capability in response to some user requests.
        Chris
        >
        > Stef Mientki
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >

        --
        Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl
      • Stef Mientki
        hi Chris, this sounds very interesting, ... that s very small !! ... that s on my todo-list to put on top of JAL. I think it s a must for complex or large
        Message 3 of 9 , Apr 8, 2005
        • 0 Attachment
          hi Chris,

          this sounds very interesting,

          nisma@... wrote:

          >>>Please comment it shortly.
          >>>
          >>>
          >>>
          >>>
          >>Sorry no answer, but if I understand you well ...
          >>do you have an alternative JAL compiler,
          >>with syntax equal to PBasic ?
          >>
          >>
          >I have a small compiler (less then 500 lines of source +rtl )
          >
          that's very small !!

          > that accept
          >XML (flowchart),
          >
          that's on my todo-list to put on top of JAL.
          I think it's a must for complex or large statemachines I often use.

          > PBasic and syntax similar to Jal generating asm files as
          >result.
          >
          >
          Sounds good,
          so now you just have to add human language to that list ;-)

          >The compiler can invoke gpasm or other assemblers in order to produce a hex
          >file. Principal differences to Jal: string support,
          >
          also on my todo list (to place on top of JAL)

          > no buildin assembler and
          >simulator, no support for assertions and the subscript operator is a dot
          >instead of the colon. All the syntax can be mixed.
          >
          >
          Very intriguing,
          yes I want to see it, is that possible ?

          >Currently i modify the syntax in order to be compatible with jal and adding
          >some class/module capability in response to some user requests.
          >
          >
          Sounds like a number of people are using it already.
          Is it freeware/shareware ?
          Is there a website were we can see it ?

          great Chris,
          I love these kinds of initiatives.

          Stef
        • xx xx
          Hi Stef, i principally have tree differences to jal. 1) foo bar - is a comment on Pbasic 2) foo.bar - . is a selector for structs and substripts and
          Message 4 of 9 , Apr 8, 2005
          • 0 Attachment
            Hi Stef,
            i principally have tree differences to jal.
            1) foo'bar -> ' is a comment on Pbasic
            2) foo.bar -> . is a selector for structs and substripts and casts
            example:
            bar = eeprom[i] -- read a byte from eeprom
            foo = eeprom[3].word -- read a word from eeprom
            output.led = !output.led -- toggle output on a cio
            extension
            foo = bar.word[2] -- get out the second LSW
            3) foo:bar -> : is used as slice operator or as short form of TO
            foo = bar[4:12] -- equivalent to this in C
            foo=(bar>>4)&((1<<<(12-4))-1)
            or substring on strings ...
            foo.word = bar.byte[2:3] is annother usage.

            I tend to use foo#bar instead to foo'bar. foo`bar is a alternative.
            The reason why i tend to foo#bar is, that # has already a special meaning
            and is used for binary operators [ # ] as example and for issuing
            compile time errors/warning. Ex.
            If typeof(arg) <> string_t #error "Function require a string as parameter"
            Adding a hook for read/write access to variables is considered a debug
            hook on other languages.
            Should i write a wrapper, that changes
            `:' -> `.'
            `\'' -> `#'
            `--' -> `\'' ++ / -- is handy for optimized pointer operations.
            and rewrite the jal manual accordly denaying compiling .jal extensions.
            Jal sources can be converted to .bas after passing on such a simple
            converter.
            Pbasic is really powerfull in some domains (rs232,printf,scanf) and less
            errorprone as printf/scanf constructs for non C programmers.
            So mixing jal/pbasic is surely the usual way.
            lookup val ,(100,200,400,500) ,res
            has a jal equivalent:
            res = lookup ( val , 100,200,400,500 )
            this don't have it.
            serout dbg , N96 , "test" , # val , $ val , CR
            serin2 gps , NEMA , 30000, "$GPRMB" , #time , #dir , ... , $checksum
            The only equivalent can be
            dbg_fs = fopen(dbg,N96)
            fprintf(dbg_fs,"test %d %#x \n",val,val)
            fscanf(dbg_fs,"$GPRMB %d %d ... %x",@time,@dir,...,@checksum)
            but this introduces several issues that generate more code and problems.
            On Pbasic, no nested function call is allowed.
            On Jal, there IS. This gives memory problems (buffers) and side effects +
            problems, if a user write a wrong format string.
            On Pbasic, the serout opens a serial port and use it (FSR/INDF) is atomic.
            On Jal, more file pointers can be open and used interleaved,
            requiring additional hidden FSR register and exchanges.

            The parsing differences is:
            <string> -- function call -> jal
            <string> <expr> {, <expr>} Pbasic
            symbol xxx = value -> symbol is a alias to constant , string constant
            allowed
            in jal, <expr:id> <expr> never happens, so this is a Pbasic construct
            and is interpreted as the follow function call.
            <expr:id> ( <expr> )


            > hi Chris,
            >
            > this sounds very interesting,
            >
            > nisma@... wrote:
            >
            > >>>Please comment it shortly.
            > >>>
            > >>>
            > >>>
            > >>>
            > >>Sorry no answer, but if I understand you well ...
            > >>do you have an alternative JAL compiler,
            > >>with syntax equal to PBasic ?
            > >>
            > >>
            > >I have a small compiler (less then 500 lines of source +rtl )
            > >
            > that's very small !!
            >
            > > that accept
            > >XML (flowchart),
            > >
            > that's on my todo-list to put on top of JAL.
            > I think it's a must for complex or large statemachines I often use.
            >
            > > PBasic and syntax similar to Jal generating asm files as
            > >result.
            > >
            > >
            > Sounds good,
            > so now you just have to add human language to that list ;-)
            >
            > >The compiler can invoke gpasm or other assemblers in order to produce a
            > hex
            > >file. Principal differences to Jal: string support,
            > >
            > also on my todo list (to place on top of JAL)
            >
            > > no buildin assembler and
            > >simulator, no support for assertions and the subscript operator is a dot
            > >instead of the colon. All the syntax can be mixed.
            > >
            > >
            > Very intriguing,
            > yes I want to see it, is that possible ?
            Can you test the jal integration and compatibility ? I could offer you a
            full version licence. This includes multitasking/concurrent tasks and
            a state machine compiler in addition to other librarys.
            > >Currently i modify the syntax in order to be compatible with jal and
            > adding
            > >some class/module capability in response to some user requests.
            > >
            > >
            > Sounds like a number of people are using it already.
            Some , mostly in educational institutions.
            > Is it freeware/shareware ?
            Compiler freeware, advanced flowchart (with subcharts) + OS kit and other
            supporting librarys (I2C slave,Gps,cordic,Wifi ...) is not free.
            > Is there a website were we can see it ?
            >
            > great Chris,
            > I love these kinds of initiatives.
            >
            > Stef
            >
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            >
            >

            --
            Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl
          • Wouter van Ooijen
            ... Do you have any figures on the asm size generated by the Jal compiler compared to generated by your translator? Take a non-trivial program, for instance
            Message 5 of 9 , Apr 8, 2005
            • 0 Attachment
              > I have a small compiler (less then 500 lines of source +rtl )
              > that accept
              > XML (flowchart), PBasic and syntax similar to Jal generating
              > asm files as result.

              Do you have any figures on the asm size generated by the Jal compiler
              compared to generated by your translator? Take a non-trivial program,
              for instance the Wisp628 source?

              Wouter van Ooijen

              -- -------------------------------------------
              Van Ooijen Technische Informatica: www.voti.nl
              consultancy, development, PICmicro products
              docent Hogeschool van Utrecht: www.voti.nl/hvu
            • nisma@gmx.net
              generally smaller (~20%). Comparsion with the hitech C compiler has given a adveraged overhead of 15-30% including strings and arrays. The compiler is
              Message 6 of 9 , Apr 8, 2005
              • 0 Attachment
                generally smaller (~20%). Comparsion with the hitech C compiler has given a
                adveraged overhead of 15-30% including strings and arrays.
                The compiler is optimized for the 12/14 bit architectures and the sx target,
                but not for the new 16+ one.

                >
                > > I have a small compiler (less then 500 lines of source +rtl )
                > > that accept
                > > XML (flowchart), PBasic and syntax similar to Jal generating
                > > asm files as result.
                >
                > Do you have any figures on the asm size generated by the Jal compiler
                > compared to generated by your translator? Take a non-trivial program,
                > for instance the Wisp628 source?
                >
                > Wouter van Ooijen
                >
                > -- -------------------------------------------
                > Van Ooijen Technische Informatica: www.voti.nl
                > consultancy, development, PICmicro products
                > docent Hogeschool van Utrecht: www.voti.nl/hvu
                >
                >
                >
                >
                >
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
                >
                >

                --
                Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl
              • Stef Mientki
                ... Well I really don t have the time for that, but there might be others on this list who are interested. Still I ld like to see it, a general impression
                Message 7 of 9 , Apr 9, 2005
                • 0 Attachment
                  >>Very intriguing,
                  >>yes I want to see it, is that possible ?
                  >>
                  >>
                  >Can you test the jal integration and compatibility ? I could offer you a
                  >full version licence. This includes multitasking/concurrent tasks and
                  >a state machine compiler in addition to other librarys.
                  >
                  >
                  Well I really don't have the time for that, but there might be others on
                  this list who are interested.
                  Still I'ld like to see it, a general impression wouldn't take much time.
                  Succes,
                  Stef
                • Stef Mientki
                  ... That doesn t say too much. I ve seen programs, standard compiled in JAL, reaching 5k of assembler. Now if I tell JAL it s not a 16F877 but a 16F628, code
                  Message 8 of 9 , Apr 9, 2005
                  • 0 Attachment
                    nisma@... wrote:

                    >generally smaller (~20%).
                    >
                    That doesn't say too much.
                    I've seen programs, standard compiled in JAL, reaching 5k of assembler.
                    Now if I tell JAL it's not a 16F877 but a 16F628, code will shrink
                    downto less then 2k.
                    So that's reduction of 60% by just fooling the compiler,
                    I guess it wouldn't cost much more then 5 lines of code (and twice the
                    compile time),
                    to implement that ;-)

                    I don't have any knowledge of compilers,
                    but in my opinion you don't need all that fancy/theoretical code
                    optimizations,
                    except for
                    - dead code removal
                    - bank switch optimization
                    - stack minimization

                    Nevertheless, just 500 lines of code for a compiler seems very efficient
                    to me !

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