| |
Slammer
Registered: Feb 2004
Posts: 449 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 647 posts hidden. Click here to view all posts....
|
| |
Slammer
Registered: Feb 2004
Posts: 449 |
Quoting KrillQuoting SlammerIf someone needed it in Kick Assembler I think I would make a getExponentBits(d) and getMantissaBits(d) and then it would be possible to make a macro that produced any float format you like. I assumed macros to be a possibility already, but they're rather cumbersome for something that is quite native to the platform (not its CPU architecture) and should, imho, be expressible with a first-class directive.
I guess you can easily do it if you put a little restriction on the used values (Don't use very large values and don't use very small values) since you have to be a little careful not to loose bit when converting them. However, java has a doubleToLongBits() which gives the IEEE 754 double bits, so they could easily be exposed.
Why is macros cumbersome? Is it to make? (Don't know the commodore float format) or to use. You can do it as a pseudocommand, so you don't have todo the paranthesis to execute (but you will also have to skip the dot):
basicFloat 1.234
or
float 1.234 |
| |
Slammer
Registered: Feb 2004
Posts: 449 |
After giving it some thoughts, I guess there is a couple of details you have to pay attention to in the implementation... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11523 |
I doubt it makes sense to even try using those IEEE macros for producing CBM style floats - they are too different in the details. |
| |
Oswald
Registered: Apr 2002
Posts: 5127 |
frankly dont think that .float is justified because Gunnar have used it 2 times over a few decades. but it wont hurt either. I cant think of any case I'd use it. |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Quoting chatGPZI doubt it makes sense to even try using those IEEE macros for producing CBM style floats - they are too different in the details. I guess it doesn't matter much. For all practical purposes, you'd parse strings to IEEE 64-bit floats (aka "doubles") and then convert those byte-wise to the much simpler BASIC floats with some arithmetics. Inf, NaN and friends... not important for defining constants.
Quoting SlammerWhy is macros cumbersome? I guess you can't do ".float 62.23, 6.28, 1e6" analogous to .byte/.word (apart from having to define a macro/function for the purpose or including some magic library file every time you need this).
Quoting Oswaldfrankly dont think that .float is justified because Gunnar have used it 2 times over a few decades. but it wont hurt either. I cant think of any case I'd use it. Thank you for your 2 fillér. And I did mention 3 specific examples from my works plus implied at least 2 more in this thread, most of them recent, ongoing or to come.
But let's let this be this thread's last post about this topic, as i seem to be the only one to see practical value in a native 5-byte float feature for a 6502 assembler. |
| |
TWW
Registered: Jul 2009
Posts: 557 |
Quoting KrillQuoting SlammerWhy is macros cumbersome? I guess you can't do ".float 62.23, 6.28, 1e6" analogous to .byte/.word (apart from having to define a macro/function for the purpose or including some magic library file every time you need this).
Regarding this; Why not add a command line option (Manual - Appendix A - Table A.1.) which allows importing source files?
This would allow you to import f.eks. a 'magic library' fP-function as requested here (can't be that hard to write a function to do this) and then add this command line option to the KickAss.cfg file in the KA folder (Ref. 2.3. in the manual). This way these functions are always included (almost like they were internal :D) and would not have to be referenced each time you need them. |
| |
Oswald
Registered: Apr 2002
Posts: 5127 |
"Why not add a command line option (Manual - Appendix A - Table A.1.) which allows importing source files?"
how to make a simple task overcomplicated tm. and then it all gets forgotten and the source gets used by someone else, who wonders where the fuck is that macro referenced when nothing is in the source. |
| |
Slammer
Registered: Feb 2004
Posts: 449 |
Quoting chatGPZI doubt it makes sense to even try using those IEEE macros for producing CBM style floats - they are too different in the details.
Could you elaborate on that? I have noted that the exponents are different, so giving the exponent directly, not as bits, will save a couple of lines, so exposing that too will make it easier. But could you explain how the fraction bits differ?
(btw, it is functions, not macros. The macro/pseudocommand is up to you to implement using the functions)
NB.You should update your 'Opcode naming in different Assemblers' table in the NoMoreSecrets docs as it got outdated in 2014. These updates are missing, perhaps more.
18/11-2014 : New beta release (v3.37):
Added illegal nop opcodes (nop #$01 - nop $02 - nop $03,x - nop $1000 - nop $1000,x)
2/5-2021 : New release (v5.20):
Added aliases for illegal opcodes: lax=lxa, dcp=dcm, isc=ins=isb, alr=asr, xaa=ane, axs=sbx, ahx=sha, tas=shs, las=lae=lds.
You can find the KickAss opcodes here.
https://theweb.dk/KickAssembler/webhelp/content/apas03s02.html |
| |
Slammer
Registered: Feb 2004
Posts: 449 |
Quoting TWWRegarding this; Why not add a command line option (Manual - Appendix A - Table A.1.) which allows importing source files?
This would allow you to import f.eks. a 'magic library' fP-function as requested here (can't be that hard to write a function to do this) and then add this command line option to the KickAss.cfg file in the KA folder (Ref. 2.3. in the manual). This way these functions are always included (almost like they were internal :D) and would not have to be referenced each time you need them.
Great idea. It is hereby noted. Until implemented, it is possible to create your own custom version of KickAss with the macros you wan't by opening the jar file (with a zip program), find the autoinclude.asm file and place it there.
[Oswald] If you are worried about the kickass.jar / KickAss.cfg is missing when someone else is going to compile simply put it in your repository. I would say the problem would be much larger if you have a large toolchain with dedicated tools, you should remember to install and configure. In the end I guess its all boils down to "It's easier for you to work with other peoples code if they use the tools you already know", but that is the same for everybody. |
| |
Oswald
Registered: Apr 2002
Posts: 5127 |
I dont use repository, its just a source file and an assembler and a few data files generated in vb6 or python, I dont like to overcomplicate things. but whatever floats your boat, hide the source include in some .cfg file you will forget even exists, its much nicer to be able to see it in the main source right away. but that is just my opinion, you do it as you like. |
| Previous - 1 | ... | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 - Next |
