Shop OBEX P1 Docs P2 Docs Learn Events
SOLVED !!! Hub Exec Error Raises Head Again On DE0_Nano Bare Board in Prop2_FPGA_11_09_15b - Page 2 — Parallax Forums

SOLVED !!! Hub Exec Error Raises Head Again On DE0_Nano Bare Board in Prop2_FPGA_11_09_15b

2»

Comments

  • jmg wrote: »
    78rpm wrote: »
    Some commands are C like commands, others are assembler directives and start with an inital period.

    It would also allow you to easily do loops using C style constructs, ie make the code less verbose and reduce coding and run-time errors.

    Sounds useful. Will this allow GAS code like
    .rept Count
    ...
    .endr
    .macro
    ...
    .endm
    

    Yes, I am planning on implementing these:
    The Special Dot Symbol
    
    The special symbol . refers to the current address that as is assembling
    into. Thus, the expression melvin: .long . defines melvin to contain its
    own address. Assigning a value to . is treated the same as a .org directive.
    Thus, the expression .=.+4 is the same as saying .space 4.
    
    eg.
            ' a C like construct
         if( ( x == b && y <= t ) || boolean )
         endif
    
           ' macro assembler directive
         .if conditional_asm_code_set_1
         .endif
    
    
         .macro
         .endm
    
    .align
    .elseif
    .func
    .endfunc
    .fill
    .irp
    .irpc
    .rept
    .endr
    .set
    .size
    .struct
    .include
    .incbin
    .file
    .equ
    .equiv
    

    It would be a quick and dirty C, an unoptimised version. I am writing it as a console application under windows with standard C library, so should be easily postable to linux, raspi. It may even manage to be a self hosted facility, if I can pick up some header files and library functions with a suitable license. May need to look to BSD for use with MIT licence?

    The file handling can use an updated OBEX version possibly. The other functions can either be from library or I can create my own. Printf style is an obvious one I use, isalpha etc, all nice and easy and small.

    So far I can read file, tokenise, identify all the correct punctuators, convert infix to RPN with SPIN precedence and process that RPN. What I have still to do is:
    1. Evaluate the expression if necessary, for '.if'
    2. Evaluate expression and generate code, for C style 'if' embedded in the PASM.

    For the latter I may use a dot command or special word to switch between PASM and C ie, perhaps use PASM and TO_C. That way you can freely mix C and PASm in a file. I wish to make use of the carry and zero flags as C and Z in C style code.
            mov     my_reg, #26
    TO_C   if( my_reg > 10 && C ) 
                  my_other_Reg <<= 1;
    PASM   ret
    
    It will, just work. It is still definitely a work in progress.
  • jmgjmg Posts: 15,175
    78rpm wrote: »

    For the latter I may use a dot command or special word to switch between PASM and C ie, perhaps use PASM and TO_C. That way you can freely mix C and PASm in a file.

    Interesting - and that would also allow asm line-comment of ; and c line-comments of //

    Is it easy to add trans functions, like .fcos(), .fsin(), .fexp() for generating tables and curve fitting ?
  • jmg wrote: »
    78rpm wrote: »

    For the latter I may use a dot command or special word to switch between PASM and C ie, perhaps use PASM and TO_C. That way you can freely mix C and PASm in a file.

    Interesting - and that would also allow asm line-comment of ; and c line-comments of //

    Is it easy to add trans functions, like .fcos(), .fsin(), .fexp() for generating tables and curve fitting ?
    I am tokenising pip "'" comments and {} block comments at present, there is no reason the ";" comment could not be used. The number of times I have typed it in PNut is uncountable.

    I think it can easily do all of C without too much trouble. Memory is the biggest constraint. but with 512K a lot is possible and can always spool to SD card if necessary.
    Is it easy to add trans functions, like .fcos(), .fsin(), .fexp() for generating tables and curve fitting ?

    I had not considered those, but I see no reason why they can not be included at some point. Would possibly need to then pick up a suitable proven floating point library, if self hosted, it would save time and testing. Any type of table you desired could be included. Linear function interpolation is another example.

    The only limit is your imagination.

    Oh, and 512K - $400 * 4 - 128 (for events and debug)

    It may be an interim tool until GCC is available for x86 / raspi systems, then that can do the optimisation properly, unless I get ambitious. :smile:
  • 78rpm wrote: »
    The Special Dot Symbol
    
    The special symbol . refers to the current address that as is assembling
    into. Thus, the expression melvin: .long . defines melvin to contain its
    own address. Assigning a value to . is treated the same as a .org directive.
    Thus, the expression .=.+4 is the same as saying .space 4.
    

    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
  • 78rpm wrote: »
    The Special Dot Symbol
    
    The special symbol . refers to the current address that as is assembling
    into. Thus, the expression melvin: .long . defines melvin to contain its
    own address. Assigning a value to . is treated the same as a .org directive.
    Thus, the expression .=.+4 is the same as saying .space 4.
    

    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
    I can do that, too. The reason I picked up on the "dot" method is because that is what GAS uses, so rather than invent my own macro directives, etc, I thought better to use something which will be available at some point in the future, from a transferring of code between the two systems. True, the PASM may not be the same, but I thought I would go for what is most likely to follow. I do not know what the SPIN equivalent for P2 will be. I suspect it will have PASM blocks as PT currently does. The less to change, the less likely to introduce new errors. And I attract errors like ... well ... an error attracting thing! :smile:


  • cgracey wrote: »
    78rpm,

    I updated that file twice yesterday, but didn't change the 'b' to a 'c', like I should have.

    You should be using the DE0_Nano_Bare_Prop2_v4c.jic file. Can you confirm?

    That's quite an awesome test program you made!

    Suggest you consider post-fixing the file names with the actual date, ie. DE0_Nano_Bare_Prop2_v10-11-15.jic ?
  • jmgjmg Posts: 15,175
    78rpm wrote: »
    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
    I can do that, too. The reason I picked up on the "dot" method is because that is what GAS uses, so rather than invent my own macro directives, etc, I thought better to use something which will be available at some point in the future, from a transferring of code between the two systems.
    Certainly makes sense to support GAS, but $ is also a widespread ASM symbol for Current Address, and it seems possible to support both.
    Rather like allowing either 0xFF or 0FFH.


  • jmg wrote: »
    78rpm wrote: »
    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
    I can do that, too. The reason I picked up on the "dot" method is because that is what GAS uses, so rather than invent my own macro directives, etc, I thought better to use something which will be available at some point in the future, from a transferring of code between the two systems.
    Certainly makes sense to support GAS, but $ is also a widespread ASM symbol for Current Address, and it seems possible to support both.
    Rather like allowing either 0xFF or 0FFH.

    Fear not, I shall implement the $ ... because it makes cents!
  • jmg wrote: »
    78rpm wrote: »
    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
    I can do that, too. The reason I picked up on the "dot" method is because that is what GAS uses, so rather than invent my own macro directives, etc, I thought better to use something which will be available at some point in the future, from a transferring of code between the two systems.
    Certainly makes sense to support GAS, but $ is also a widespread ASM symbol for Current Address, and it seems possible to support both.
    Rather like allowing either 0xFF or 0FFH.

    Rather than supporting GAS syntax, how about helping to retarget the real GAS to the P2? That would move the P2 PropGCC effort along nicely.

  • David Betz wrote: »
    jmg wrote: »
    78rpm wrote: »
    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
    I can do that, too. The reason I picked up on the "dot" method is because that is what GAS uses, so rather than invent my own macro directives, etc, I thought better to use something which will be available at some point in the future, from a transferring of code between the two systems.
    Certainly makes sense to support GAS, but $ is also a widespread ASM symbol for Current Address, and it seems possible to support both.
    Rather like allowing either 0xFF or 0FFH.

    Rather than supporting GAS syntax, how about helping to retarget the real GAS to the P2? That would move the P2 PropGCC effort along nicely.

    Hello David. Well, that sounds like a real GAS! Thank you for extending the invitation.

    Can you point me in the right direction for an overview of the internals for the version we will be using?
  • 78rpm wrote: »
    David Betz wrote: »
    jmg wrote: »
    78rpm wrote: »
    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
    I can do that, too. The reason I picked up on the "dot" method is because that is what GAS uses, so rather than invent my own macro directives, etc, I thought better to use something which will be available at some point in the future, from a transferring of code between the two systems.
    Certainly makes sense to support GAS, but $ is also a widespread ASM symbol for Current Address, and it seems possible to support both.
    Rather like allowing either 0xFF or 0FFH.

    Rather than supporting GAS syntax, how about helping to retarget the real GAS to the P2? That would move the P2 PropGCC effort along nicely.

    Hello David. Well, that sounds like a real GAS! Thank you for extending the invitation.

    Can you point me in the right direction for an overview of the internals for the version we will be using?
    The current sources for the PropGCC version of GAS is part of the binutils project:

    https://github.com/totalspectrum/binutils-propeller
  • jmgjmg Posts: 15,175
    78rpm wrote: »
    David Betz wrote: »
    Rather than supporting GAS syntax, how about helping to retarget the real GAS to the P2? That would move the P2 PropGCC effort along nicely.

    Hello David. Well, that sounds like a real GAS! Thank you for extending the invitation.

    Can you point me in the right direction for an overview of the internals for the version we will be using?

    Sounds like a very good idea - then you can test the ASM-Pre-processor, and some tweaks to GAS to help converge to PNUT2 may help too.

  • David Betz wrote: »
    78rpm wrote: »
    David Betz wrote: »
    jmg wrote: »
    78rpm wrote: »
    Why don't you use $ instead of . for current address, since PNUT uses $ for current address?

    "melvin long $" is valid PASM that does the same as your "melvin: .long .".
    I can do that, too. The reason I picked up on the "dot" method is because that is what GAS uses, so rather than invent my own macro directives, etc, I thought better to use something which will be available at some point in the future, from a transferring of code between the two systems.
    Certainly makes sense to support GAS, but $ is also a widespread ASM symbol for Current Address, and it seems possible to support both.
    Rather like allowing either 0xFF or 0FFH.

    Rather than supporting GAS syntax, how about helping to retarget the real GAS to the P2? That would move the P2 PropGCC effort along nicely.

    Hello David. Well, that sounds like a real GAS! Thank you for extending the invitation.

    Can you point me in the right direction for an overview of the internals for the version we will be using?
    The current sources for the PropGCC version of GAS is part of the binutils project:

    https://github.com/totalspectrum/binutils-propeller

    Thank you. I will wander there shortly.
  • jmg wrote: »
    78rpm wrote: »
    David Betz wrote: »
    Rather than supporting GAS syntax, how about helping to retarget the real GAS to the P2? That would move the P2 PropGCC effort along nicely.

    Hello David. Well, that sounds like a real GAS! Thank you for extending the invitation.

    Can you point me in the right direction for an overview of the internals for the version we will be using?

    Sounds like a very good idea - then you can test the ASM-Pre-processor, and some tweaks to GAS to help converge to PNUT2 may help too.

    I hope I do not become horribly confused with the two syntaxes (syntii?).

    The greater the similarity of GAS and PNut, the easier porting between the two will b, for those going the GAS & GCC route, and those who follow PASM & SPIN.

    Rather than loose our discussion in this thread, I started a new one here where we can continue, a couple of days old now.

    forums.parallax.com/discussion/162742/help-is-the-high-level-assembler-essentially-like-pasm-please-moderator-move-some-messages

    I thinkk you'll get the gist.
Sign In or Register to comment.