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.
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 ?
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.
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 .".
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!
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.
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!
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.
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?
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:
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:
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.
Comments
Yes, I am planning on implementing these:
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. It will, just work. It is still definitely a work in progress.
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 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.
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.
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 .".
Suggest you consider post-fixing the file names with the actual date, ie. DE0_Nano_Bare_Prop2_v10-11-15.jic ?
Rather like allowing either 0xFF or 0FFH.
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?
https://github.com/totalspectrum/binutils-propeller
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.
Thank you. I will wander there shortly.
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.