| |
Sasq
Registered: Apr 2004
Posts: 155 |
Wanted: Source codes (for badass)
In order to improve my assembler it would be great to try it on existing projects.
So if you have sources for demos/intros/games that you don't mind sharing it would be kind if you could send them my way, and I'll try to get them working in bass.
They need to be buildable the normal way (Kickass, Acme or whatever) so I can compare the output binaries...
(this also means that if your type of demos requires special tools there is a greater chance I will include such functionality in bass).
-- sasq64@gmail.com |
|
... 65 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2852 |
Quoting tlr$100 - 15 would be a better example. If the result is interpreted as zp, then the behaviour would be different.
Your idea with mem16 would solve that case if I understand it correctly. I think most sensible would be to remain with the mem16 type in such a case. Then there is no implicit type demotion from mem16 to ZP, which i think would do more harm than good anyways. There was a 16-bit address on the way somewhere, probably for a good reason. :)
But then yeah, maybe what Groepaz said. Might be a good idea to have an option (default setting to be discussed) to force the programmer to mark the result type explicitly if the individual types within an expression are mixed. Then there is no implicit type conversion in any direction. This might be a bit annoying, as i'd prefer "$0100 + 15" over "$0100 + $000f" for getting 16-bit memory access without any warnings or errors. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: I'd prefer those ambigious cases to just show an error, so i am forced to write into the code explicitly what i mean/want. All those "smart" automatisms *will* fail to do what you intended in one case or another - and result in a night of WTF
Agreed |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I would skip the whole math and just use what's in the code, that is.
lda $f0 + $0A = lda $00 (still zp)
lda $00f0 + $0a = lda $0100
But since Sasq says it's more complicated to parse or whatever... well, too bad. I'm just saying what I'd be happy with |
| |
Krill
Registered: Apr 2002
Posts: 2852 |
Quoting GolaraI would skip the whole math and just use what's in the code, that is.
lda $f0 + $0A = lda $00 (still zp)
lda $00f0 + $0a = lda $0100
But since Sasq says it's more complicated to parse or whatever... well, too bad. I'm just saying what I'd be happy with This seems to be the "largest type in expression determines access size" and "no type demotion" idea i detailed above. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: Quoting GolaraI would skip the whole math and just use what's in the code, that is.
lda $f0 + $0A = lda $00 (still zp)
lda $00f0 + $0a = lda $0100
But since Sasq says it's more complicated to parse or whatever... well, too bad. I'm just saying what I'd be happy with This seems to be the "largest type in expression determines access size" and "no type demotion" idea i detailed above.
Point is, I don't think the automatic optimization to ZP is necessary, ZP is pretty small and always used knowingly. Adding a postfix like lda.w sta.b would be ugly, since only few opcodes would use that and it would destroy the perfect 3 characters for opcode rule which I really like.
For numbers that are generated in a loop, like :
.for (var i = 0; i < 100; i++) {
lda i
sta i+10
}
I'd just add a static zero of a 1 or 2 bytes size
.for (var i = 0; i < 100; i++) {
lda $00 + i
sta $0000 + i + 10
}
|
| |
Sasq
Registered: Apr 2004
Posts: 155 |
There is not really an "automatic optimization". It's just that when it is time to assemble the opcode, we don't know which opcode to pick, and it makes most sense to pick the zp opcode if the argument is below $100.
I think the ideal would be something like;
* We support 3 numeric types, 8-bit, 16-bit and automatic.
* A literal matching $xxxx becomes 16-bit, $xx -> 8-bit, all others automatic.
* The type is kept during expression evaluation. If an operation causes an 8-bit value to overflow, then that is an _error_.
* An automatic type is converted to 8 or 16-bit depending on size when it is time to assemble the opcode. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
There are special cases though. Let's say you have some weird routine that matches zero page addresses to the lower byte of some 16-bit address. Which opcode would you expect here ?
data = $c000
sta data & $ff
|
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quote: There are special cases though. Let's say you have some weird routine that matches zero page addresses to the lower byte of some 16-bit address. Which opcode would you expect here ?
data = $c000
sta data & $ff
I think it would be reasonable if an '&' masked the size of the other operand, resulting in size 8 in this case. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
So what is the rule ? How do we know what the code actually means ?
We can't demote to 8-bit just because the value becomes < 256, that defeats the whole point. So it must be "if it looks like he REALLY means it", ie explicitly anding with constant $ff.
But what about
sta data & mask
sta data & (size-1)
sta data & (... complex expression)
madness lies here. For cases like this the programmer needs to rely on something like
sta.b data & $ff
|
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quoting SasqSo what is the rule ? How do we know what the code actually means ?
You could demote to 8-bit because one of the operands of '&' is 8-bit. Same for '%' as they are essentially wrapping operations. Not sure if there will be other bad consequences because of this though. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
