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

Welcome

Expand Messages
  • Ziya ERDEMÄ°R
    Hi and welcome to our new discussion list. As you know Jal is a powerful and easy-to-use compiler and needs tobe improved further. I have a suggestion at this
    Message 1 of 3 , Feb 28, 2003
    View Source
    • 0 Attachment
      Hi and welcome to our new discussion list.
       
      As you know Jal is a powerful and easy-to-use compiler and needs tobe improved further.
       
      I have a suggestion at this point: before adding new features to compiler, current bugs must be fixed first.  There is a huge to do list. Howerver most of them are not essential for now. Can we prepare a bug list for current version first?
       
      The bugs I know are:
      --------------------
      1. Page switching problem for 16f877. If you call a subroutine then return doesn't set program counter to the next instruction.
       
      2. There is a bug in simulator part that produces wrong 24 bit floating point logical comparision. 
       
       
      trisa, trisb, etc. hardware addresses must be defined so that user must be able to reach these addresses by using their standard names. In current Jal release user can't reach trisa, trisb with these names.
       
       
       
       
      looking forward bugfree source
       
      Ziya
    • japus10 <japus11@terra.es>
      Hi all, I just signed in, hope to be usefull. ... compiler, current bugs must be fixed first. There is a huge to do list. Howerver most of them are not
      Message 2 of 3 , Feb 28, 2003
      View Source
      • 0 Attachment
        Hi all,

        I just signed in, hope to be usefull.




        > I have a suggestion at this point: before adding new features to
        compiler, current bugs must be fixed first. There is a huge to do
        list. Howerver most of them are not essential for now. Can we prepare
        a bug list for current version first?


        Ziya, please, tell me if sourceforge will be still valid for
        managing the sources or will be done in this file area. Or, please,
        tell me what's the last valid source.


        >
        > The bugs I know are:
        > --------------------
        > 1. Page switching problem for 16f877. If you call a subroutine then
        return doesn't set program counter to the next instruction.
        >

        I'm not sure about this about this. I've been working with large
        projects and for me works well. The problem usually is the stack,
        because JAL in certain circunstances don't count well the number of
        stacks entryes and makes you to overflow this stack.



        > 2. There is a bug in simulator part that produces wrong 24 bit
        floating point logical comparision.
        >

        Have you isolated this bug? Or in other words, can we detect this
        bug with a simple test program?


        > trisa, trisb, etc. hardware addresses must be defined so that user
        must be able to reach these addresses by using their standard names.
        In current Jal release user can't reach trisa, trisb with these names.
        >

        Agree, this comes from earlier versions and I think that can be
        rewritten. This part it's in jpic.jal (and jpic16.jal).



        I've modified source (0.4.53) for 16F876 and 16f873. Should be
        better to do this part via external files instead of 2 internal
        arrays and some variables. But certain part of code is core dependant
        (compiler still want's to know all cores), so at this moment we are
        in a no-way road.




        For the first email it's enough ;-)



        Regards, Javi.
      • Ziya ERDEMIR
        Hi Javi, ... Yes ofcourse. sourceforge will be used to update source and keep new versions. This is just a discussion list and some documentation may be keep
        Message 3 of 3 , Feb 28, 2003
        View Source
        • 0 Attachment
          Hi Javi,
           
          --- In Jal_developers@yahoogroups.com, "japus10 <japus11@t...>" <japus11@t...> wrote:
          > Hi all,
          >
          >    I just signed in, hope to be usefull.

          > > I have a suggestion at this point: before adding new features to
          > compiler, current bugs must be fixed first.  There is a huge to do
          > list. Howerver most of them are not essential for now. Can we prepare
          > a bug list for current version first? 
          >
          >    Ziya, please, tell me if sourceforge will be still
          valid for
          > managing the sources or will be done in this file area. Or,
          please,
          > tell me what's the last valid source.

          Yes ofcourse. sourceforge will be used to update source and keep new versions. This is just a discussion list and some documentation may be keep here. I couldn't access sourceforge by cvs (I think due to proxy server) so I have the source with few improvements on simulator part. Did you update your improvements (for target_chip) on sourceforge?
           
           

          > > The bugs I know
          are:
          > > --------------------
          > > 1. Page switching problem
          for 16f877. If you call a subroutine then
          > return doesn't set program
          counter to the next instruction.
          > >
          >
          >    I'm not sure about this about this. I've been working
          with large
          > projects and for me works well. The problem usually is the
          stack,
          > because JAL in certain circunstances don't count well the number
          of
          > stacks entryes and makes you to overflow this
          stack.
          I am exactly sure. Because I used LCD display and lots of procedures prints something to LCD. Returning from a procedures jumps to aome part of other procedures which is not called from that procedure. Version 4.45 is also has this problem but works better than version 4.5.
           
          Later deeper stack space can be implemented. In assembler I tested an algorithm and works well, however eats 2 byte to keep PC_H and PC_L for each call.
           
           
          > > 2. There is a bug in simulator part that produces wrong 24 bit
          > floating point logical comparision. 
          > >
          >
          >    Have you isolated this bug? Or
          in other words, can we detect this
          > bug with a simple test
          program? 
               
          Not yet. But I think I can find and fix the problem.
           
          > > trisa, trisb, etc. hardware
          addresses must be defined so that user
          > must be able to reach these
          addresses by using their standard names.
          > In current Jal release user
          can't reach trisa, trisb with these names.
          > >
          >
          >   Agree, this comes from earlier versions and I think that
          can be
          > rewritten. This part it's in jpic.jal (and
          jpic16.jal).
           
          Yes. Also in jpic628.jal . I will try to modify them.  

          >   I've modified source (0.4.53) for
          16F876 and 16f873. Should be
          > better to do this part via external files
          instead of 2 internal
          > arrays and some variables. But certain part of
          code is core dependant
          > (compiler still want's to know all cores), so at
          this moment we are
          > in a no-way road.
           
           
          In HITEC-C processor definitions are in an external file. and it is easy to implement new products into compiler just entering its properties (name, RAM & ROM size, bank adresses etc.) This kind of modification may be implemented to Jal. But I insist on fixing bugs first :-)

          > For the first email it's
          enough ;-)  
          >
          >
          >
          > Regards,
          Javi.
           
           
          Ok. Regards...
           
          Ziya
           
        Your message has been successfully submitted and would be delivered to recipients shortly.