| |
Slammer
Registered: Feb 2004
Posts: 416 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 590 posts hidden. Click here to view all posts....
|
| |
Frodo
Registered: May 2020
Posts: 2 |
Quote: Hello
I get the following error:
.if (CopyStop-CopyStart >= 256) {
^
Error: The condition must be able to evaluate in first parse
at line 57, column 5 in Asset Manager.asm
I am using the pseudopc directive. I have found a (messy) workaround but wondered if there is a way to allow two parses?
Also, any future plans to allow pseudopc nesting in the future (useful for cartridge images where you need the assembled code pseudopc to $8000, then pseudopc code to $0800 (example) which is to be copied to RAM while it all in fact is located at $2040 in the .crt image. Again, I have a workaround but wondered if this is planned or if there might be some more delicate way to handle this?
EDIT:
Simplified question:
test1:
test2:
.if ([test1 - test2] == 0) .print "This Works!"
.if ([test3 - test4] == 0) .print "This Does Not Work!"
test3:
test4:
Is there a way to get the 2nd .if statement to work without getting the "Error: The condition must be able to evaluate in first parse" issue?
Thanks for posting this!
Were you able to get this resolved by any chance?
I have the same issue with Kick Assembler v5.25.
My workaround isn't great either, e.g. bne_perf(*+2)
Thank you, |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: Thanks for posting this!
Were you able to get this resolved by any chance?
I have the same issue with Kick Assembler v5.25.
My workaround isn't great either, e.g. bne_perf(*+2)
Thank you,
Yes, you can do it like that since *+2 is known when you call the pseudo. Another workaraound is to use .label to pre-define memory locations in advance, but for branches and such this isn't a very good solution. Maybee there is a way with segments (as they seem flexible of sorts) but perhaps combersome when dealing with pseudo/macros.
An example is to get a branch-pseudo to determine if a branch should be long or short (bne label or beq *+4 + jmp label) to a label further down your code. Not trivial...
It has been explained that it's a chicken/egg issue as the unresolved label may change depending on the conditional checks (.if(sometthing) - change something) made inside the pseudocommand or macro. What perhaps could solve it is to allow additional passes to try and resolve "resolvable" labels and then tap out if it not able to do it in n times.
Either way, not sure if this is the right forum to discuss this anymore. There is a facebook group which exists (I am not on FB!) which perhaps could yield a response :)
Another feature request: Make assertions which passes silent (or an option to do so). |
| |
Avalanche
Registered: Aug 2002
Posts: 6 |
I am working with Kick-Ass now for a while. Though Slammer is giving his best, I'd love to see Kick-Ass going "open-source". Some things are buggy, some features missing, and sometimes old socks need to be cut off for better understanding of how to do things.
The FB group is a place to post, and others can like it or write comments on it. But thats all about it. Its not really a good way of taking care and responsibility upon a product-like tool. Plus: you cut off anybody else that is willing to help or would take the responsibility to add improvements/features by himself.
When it comes down to Kick-Ass' future its all depending upon Slammer, in good aswell as in bad terms. |
| |
Style
Registered: Jun 2004
Posts: 498 |
Apologies if this has been covered, I havent been following the thread, but two things Id love in kickass:
1) Overloading macros and functions
2) naming parameters in calls, cos it's clearer and will support 1
Thoughts? |
| |
Style
Registered: Jun 2004
Posts: 498 |
Oh, I forgot
3) Passing nothing to a macro parameter results in null. Or allow defaults for parameters, making the parameter optional. |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Quote: Oh, I forgot
3) Passing nothing to a macro parameter results in null. Or allow defaults for parameters, making the parameter optional.
You can do this with pseudocommands (allows "null" parameters).
I.e. add16 $1000 : #100 : (optional destination)
Depending on what it is you want to do, you can #define 'something' which alters the behavior of a macro (example):
#define WhateverCondition
:MyMacro(a, b)
#undefine WhateverCondition
#if WhateverCondition {
.MyMacro(a, b) {}
}
#else{
.MyMacro(a) {}
}
Or simply make 2 macros, one normal and one stable. But yes agree it would be a nice addition. |
| |
Stone
Registered: Oct 2006
Posts: 168 |
At one point I will ask myself:
"Am I not a man of many resources? Do I have but one tool in my toolchest? Must I be eternally bound by forces beyond my reckoning?"
And I shall hope to answer:
"Nay! I am a programmer! I refuse to be a slave to the limitations of my assembler! Henceforth I shall take destiny into my own hands! I shall make use of Python, C++ and their ilk to produce code and data as I see fit! I shall use Makefiles so that my time and powers of conversion are not unduly wasted! Then I shall be the master of my domain and I shall be at peace." |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Quoting Stone
And I shall hope to answer:
"Nay! I am a programmer! I refuse to be a slave to the limitations of my assembler! Henceforth I shall take destiny into my own hands! I shall make use of Python, C++ and their ilk to produce code and data as I see fit! I shall use Makefiles so that my time and powers of conversion are not unduly wasted! Then I shall be the master of my domain and I shall be at peace."
Such true words, let the assembler stay what it is, the tool that helps you a bit to not enter your code as hex, not less, not more, it is there for the dirty work. In my view there's no need for it to handle high-level language programming like javascript or lua. There's compilers and interpreters for those languages on their own, each of them also brings their own syntax highlighting, if you favour that. I know, we wish it to be comfortable as much as possible, but in the end it is an assembler, and not acompiler and thus subjected to certain restrictions that we need to accept. We love restrictions, right? :-) |
| |
TWW
Registered: Jul 2009
Posts: 541 |
Wasn't there like a 'bitching topic' or something people could ramble in???
If a thread sets off your (insert whatever 3-4 letter diagnosis which suits your condition) to the point where you (IN A DEDICATED THREAD TO A SPECIFIC TOOL) are compelled to call other people idiots for using said tool, here a simple solution: Don't comment or better yeat don't even read it, instead make another thread called ‘idiots who uses other tools than I’ or whatever and cut the trolling shit... |
| |
Stone
Registered: Oct 2006
Posts: 168 |
I tried to humorously point out that all tools have their limitations, even something as flexible as Kick Asm. I use at least 4 assemblers regularly and one of them is Kick Asm but when I get into a situation where I need interlinked code/table generation or some kind of data conversion I usually use an offline tool or script, not because the problem can't be solved in my assembler but because it is easier to debug my own program and it does exactly what I want it to do, no more and no less. Of course, trying to solve a problem within the limitations of your chosen tool can be a fun and rewarding challenge in itself even though it may not be the most productive way.
What I think is specific to this thread (and the Facebook group) is that users seem to ask for increasingly obscure features to be added to the assembler to solve their edge cases instead of taking a step back and look at how we work. |
| Previous - 1 | ... | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 - Next |
