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

Using case ... of in jal v2

Expand Messages
  • Seb
    Dear Jal guys, First of all, may 2007 be a great year for you all ! I m currently trying to use the case ... of feature of jal v2, but I ve observed strange
    Message 1 of 3 , Jan 2, 2007
    • 0 Attachment
      Dear Jal guys,

      First of all, may 2007 be a great year for you all !

      I'm currently trying to use the "case ... of" feature of jal v2, but
      I've observed strange things that occurs... Here the test case:

      -- -------------------
      include 16f628_bert

      var byte data
      const char_a = "a"
      case data of
      char_a: serial_sw_write("b")
      -- "a": serial_sw_write("b")
      end case
      -- -------------------

      This actually compiles ok, but produces some weird messages. Here the
      output:
      generating p-code
      [... some usual warnings]
      0 errors, 13 warnings
      320 tokens, 125079 chars; 3566 lines; 13 files
      generating PIC code pass 1
      generating PIC code pass 2
      writing result
      Code area: 112 of 2048 used
      Data area: 4 of 224 used
      Software stack available: 88 bytes
      Hardware stack depth 2
      !!! tag 0x80f9458: char_a(1) ct = 2
      !!! tag 0x8107630: _btemp66(1) ct = 2
      !!! tag 0x81071b8: _l412(1) ct = 2
      !!! tag 0x8107160: _l411(1) ct = 2
      !!! tag 0x8106fd0: _floop24(1) ct = 2
      !!! tag 0x8106c58: _l410(1) ct = 2
      !!! tag 0x8106c00: _l409(1) ct = 2
      !!! tag 0x8106ba8: delay_5s(2) ct = 2
      !!! tag 0x81067f0: _btemp65(1) ct = 2
      !!! tag 0x8106360: _l408(1) ct = 2
      !!! tag 0x8106308: _l407(1) ct = 2
      !!! tag 0x8106178: _floop23(1) ct = 2
      !!! tag 0x8105e10: _l406(1) ct = 2
      [... lots of message of this kind]


      While switching the case block with:

      case data of
      -- char_a: serial_sw_write("b")
      "a": serial_sw_write("b")
      end case

      the program compiles without those "!!! tag ..." messages. Diffing the
      asm and hex files gives no differences, so this seems not to be a big
      issue, but my question is why those 2 lines are not behaving the same
      ? Can't I use a constant as a "case entry" ?

      Thanks in advance for your help

      Cheers

      Seb
      --
      Seb
      sirloon[at]sirloon.net
      http://www.sirloon.net
    • zmafoox
      Greetings, ... It s a bug (the first of 07 woo! woo!). It simple means somewhere I forgot to release the reference to `char_a which usually results in a lot
      Message 2 of 3 , Jan 3, 2007
      • 0 Attachment
        Greetings,

        --- In jallist@yahoogroups.com, "Seb" <sirloon@...> wrote:
        >
        > Dear Jal guys,
        >
        > First of all, may 2007 be a great year for you all !
        >
        > I'm currently trying to use the "case ... of" feature of jal v2, but
        > I've observed strange things that occurs... Here the test case:
        >
        > -- -------------------
        > include 16f628_bert
        >
        > var byte data
        > const char_a = "a"
        > case data of
        > char_a: serial_sw_write("b")
        > -- "a": serial_sw_write("b")
        > end case
        > -- -------------------
        >
        > This actually compiles ok, but produces some weird messages. Here the
        > output:
        > generating p-code
        > [... some usual warnings]
        > 0 errors, 13 warnings
        > 320 tokens, 125079 chars; 3566 lines; 13 files
        > generating PIC code pass 1
        > generating PIC code pass 2
        > writing result
        > Code area: 112 of 2048 used
        > Data area: 4 of 224 used
        > Software stack available: 88 bytes
        > Hardware stack depth 2
        > !!! tag 0x80f9458: char_a(1) ct = 2
        > !!! tag 0x8107630: _btemp66(1) ct = 2
        > !!! tag 0x81071b8: _l412(1) ct = 2
        > !!! tag 0x8107160: _l411(1) ct = 2
        > !!! tag 0x8106fd0: _floop24(1) ct = 2
        > !!! tag 0x8106c58: _l410(1) ct = 2
        > !!! tag 0x8106c00: _l409(1) ct = 2
        > !!! tag 0x8106ba8: delay_5s(2) ct = 2
        > !!! tag 0x81067f0: _btemp65(1) ct = 2
        > !!! tag 0x8106360: _l408(1) ct = 2
        > !!! tag 0x8106308: _l407(1) ct = 2
        > !!! tag 0x8106178: _floop23(1) ct = 2
        > !!! tag 0x8105e10: _l406(1) ct = 2
        > [... lots of message of this kind]
        >
        >
        > While switching the case block with:
        >
        > case data of
        > -- char_a: serial_sw_write("b")
        > "a": serial_sw_write("b")
        > end case
        >
        > the program compiles without those "!!! tag ..." messages. Diffing the
        > asm and hex files gives no differences, so this seems not to be a big
        > issue, but my question is why those 2 lines are not behaving the same
        > ? Can't I use a constant as a "case entry" ?

        It's a bug (the first of '07 woo! woo!). It simple means somewhere I
        forgot to release the reference to `char_a' which usually results in a
        lot of tags not being released.

        I'll take a look & see what I find.

        --kyle
      • Seb
        Thanks for your reply ! ... Can you confirm the resulting asm code is ok even if those tags aren t released ? ... Great! Let me know if you need other
        Message 3 of 3 , Jan 4, 2007
        • 0 Attachment
          Thanks for your reply !

          > It's a bug (the first of '07 woo! woo!). It simple means somewhere I
          > forgot to release the reference to `char_a' which usually results in a
          > lot of tags not being released.
          Can you confirm the resulting asm code is ok even if those tags aren't
          released ?


          > I'll take a look & see what I find.
          Great! Let me know if you need other information or if I can do
          something... I'll be glad to help :)

          Cheers,

          --
          Seb
          sirloon[at]sirloon.net
          http://www.sirloon.net
        Your message has been successfully submitted and would be delivered to recipients shortly.