| |
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 tlrI thought you didn't like it being explicitly annotated? Maybe I assumed wrong? I'd prefer no annotations, but with annotations, i'd prefer them on the opcodes, not the operands. |
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quote: Quoting tlrI thought you didn't like it being explicitly annotated? Maybe I assumed wrong? I'd prefer no annotations, but with annotations, i'd prefer them on the opcodes, not the operands.
I too obviously prefer them on the opcodes. Paradoxically, allowing them implicitly would actually need to attach that property to the operand though. Allowing both implicit and explicit will need resolution code to handle some corner cases when the operand property conflicts with explicit opcode size.
It wouldn't be entierly weird to allow size extensions to the actual operand btw, e.g $00.w or (5 + 2).b. IIRC 68k asms have such constructs. Again, 64tass has _loads_ of such features, but syntax can always be argued about. :) |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
I have now refactored the assembler into using an AST for parsing, so parsing does not have to happen for every pass, and not for every rept, define or other block.
For instance, a !rept 30000 { opcode } is now around 15x faster.
It also means the parser can become a lot more advanced. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: I too obviously prefer them on the opcodes. Paradoxically, allowing them implicitly would actually need to attach that property to the operand though. Allowing both implicit and explicit will need resolution code to handle some corner cases when the operand property conflicts with explicit opcode size.
It wouldn't be entierly weird to allow size extensions to the actual operand btw, e.g $00.w or (5 + 2).b. IIRC 68k asms have such constructs. Again, 64tass has _loads_ of such features, but syntax can always be argued about. :)
well 68k, x86 and any other arch needs this kind of syntax since they can load 8, 16, 32+ bit words. On 6502 you only need a distinction because of the zero page. I'd rather have the one byte address be always ZP and 2 byte address always be a full address, i.e
lda $00 = zp load
lda $000 = normal load |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
As was mentioned earlier, this requires the size of a Number to be part of the numeric token, and propagate through expressions -- meaning you need C-like promotion of different integer types.
Could for sure be done, but not something I would do now.
If I create a "promotable" type system for other reasons (to make it easier to do things like combine arrays, numbers and lambdas in expressions) then I may add support for it. |
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quote: well 68k, x86 and any other arch needs this kind of syntax since they can load 8, 16, 32+ bit words. On 6502 you only need a distinction because of the zero page. I'd rather have the one byte address be always ZP and 2 byte address always be a full address, i.e
lda $00 = zp load
lda $000 = normal load
Yes, but what about things like: lda lab,x
lab equ $f0 + 15 Do you want lda <abs>,x or lda <zp>,x? |
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quote: I have now refactored the assembler into using an AST for parsing, so parsing does not have to happen for every pass, and not for every rept, define or other block.
For instance, a !rept 30000 { opcode } is now around 15x faster.
It also means the parser can become a lot more advanced.
Yay! An AST really pays off.
All this discussion actually got inspired to update mine a bit too. My aim might be a bit different though, although I noticed I'd put lua scripting in the TODO too. :) |
| |
Krill
Registered: Apr 2002
Posts: 2852 |
Quoting tlrYes, but what about things like: lda lab,x
lab equ $f0 + 15 Do you want lda <abs>,x or lda <zp>,x? Sum is $ff, so this is not really ambiguous yet, i guess.
I'd implement the type promotion from ZP to mem16 access to happen when the result is at least $0100.
If this would belab = $00f0 + 15 instead, it would mean mem16 access, as the biggest type is mem16 in that expression.
But there should be some way to explicity force ZP access on a symbol (when all operands in an expression have type ZP but result in a value >255).
Could be as simple as "symbol = <( ... bla... expression )", though. :) |
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quoting KrillQuoting tlrYes, but what about things like: lda lab,x
lab equ $f0 + 15 Do you want lda <abs>,x or lda <zp>,x? Sum is $ff, so this is not really ambiguous yet, i guess.
I'd implement the type promotion from ZP to mem16 access to happen when the result is at least $0100.
If this would belab = $00f0 + 15 instead, it would mean mem16 access, as the biggest type is mem16 in that expression. It was probably a bad example. $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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
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 |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
