| |
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....
|
| |
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: 1735 |
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: 1735 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11159 |
Quote:How do we know what the code actually means ?
you write it, explicitly :) |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
This would mean that
table:
!fill 256
end:
size = table-end
sta data & (size-1)
sta data & $ff
would generate different opcodes, because size is not 8-bit
All this would require a complicated type and promotion system, and you could only get it to do _almost_ what you want.
I think
sta ; addressing mode depends on operand
sta.b ; zp
sta.w ; 16-bit
is probably the simplest/best way to do it. |
| |
Raistlin
Registered: Mar 2007
Posts: 585 |
Or just use sta.zp and sta.abs in the same way as KickAss? |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
Sure, what you call the suffix is no too important :)
Probably .8 .b .zp .z should all be synonyms
And .w .16 .abs |
| |
chatGPZ
Registered: Dec 2001
Posts: 11159 |
.whatimean |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
