| |
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: 2855 |
Quoting tlrTricky case. Do you have a suggestion for a good rule for this except in the trivial case with a constant? I'm mostly interested in the trivial case where there are 16-bit values with a zero high-byte as literal operands (to be used with self-modifying and unrolled code).
When going via indirections (labels, symbols, expressions), explicitly marking 16-bit access the traditional way is okay. |
| |
tlr
Registered: Sep 2003
Posts: 1728 |
Quote: Quoting tlrTricky case. Do you have a suggestion for a good rule for this except in the trivial case with a constant? I'm mostly interested in the trivial case where there are 16-bit values with a zero high-byte as literal operands (to be used with self-modifying and unrolled code).
When going via indirections (labels, symbols, expressions), explicitly marking 16-bit access the traditional way is okay.
Recording the number of bits a constant was defined with, but maybe not propagating it through expressions would solve your use case. Might be annoying that it behaves differently if used in expression though.
I'd look a 64tass and see if and how that solves it first though. |
| |
soci
Registered: Sep 2003
Posts: 474 |
Technically possible even with labels and expressions but it'd be too fragile to rely on it. Also some people tend to write out excess zeros to line up columns nicely(?).
The suggested "trivial" case for "mnemonic $00xx" would be not okay as it results in an inconsistent special case.
Personally what I tend to do is:
lda $abcd,x ; random address as it'll be overwritten anyway
lda @w 0,x ; traditionally
Further alternatives:
lda 0,b,x ; ask for address in data bank (not restricted to 65816)
selfmod = 0,b
lda selfmod,x ; same but self descriptive
.dpage ? ; direct page independent code
lda 0,x ; therefore this won't result in B5 00 |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
Yes, i don't like any of those workarounds. :)
What about annotating the opcode, such as "lda.w $0000"?
And if that's ambiguous because it could imply reading a 16-bit value, not reading from a 16-bit address, something like "lda.m $0000"? |
| |
tlr
Registered: Sep 2003
Posts: 1728 |
Quote: Yes, i don't like any of those workarounds. :)
What about annotating the opcode, such as "lda.w $0000"?
And if that's ambiguous because it could imply reading a 16-bit value, not reading from a 16-bit address, something like "lda.m $0000"?
This is how it works in dasm, at least my fork. This is also how chose to handle it in my own assembler. .a/.w for forcing 16-bit and .z/.b for forcing 8-bit.
I thought you didn't like it being explicitly annotated? Maybe I assumed wrong? |
| |
Krill
Registered: Apr 2002
Posts: 2855 |
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: 1728 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
