Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Wanted: Source codes (for badass)
2020-10-17 08:22
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....
 
2020-11-04 13:16
tlr

Registered: Sep 2003
Posts: 1714
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?
2020-11-04 13:19
tlr

Registered: Sep 2003
Posts: 1714
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. :)
2020-11-04 13:46
Krill

Registered: Apr 2002
Posts: 2844
Quoting tlr
Yes, 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 be
lab = $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. :)
2020-11-04 17:07
tlr

Registered: Sep 2003
Posts: 1714
Quoting Krill
Quoting tlr
Yes, 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 be
lab = $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.
2020-11-04 17:23
chatGPZ

Registered: Dec 2001
Posts: 11116
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
2020-11-04 18:36
Krill

Registered: Apr 2002
Posts: 2844
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.
2020-11-04 21:24
JackAsser

Registered: Jun 2002
Posts: 1989
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
2020-11-05 12:59
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
2020-11-05 13:14
Krill

Registered: Apr 2002
Posts: 2844
Quoting Golara
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
This seems to be the "largest type in expression determines access size" and "no type demotion" idea i detailed above.
2020-11-05 13:48
Golara
Account closed

Registered: Jan 2018
Posts: 212
Quote: Quoting Golara
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
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
}
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Jetboy/Elysium
zscs
WVL/Xenon
DAM
Icecube/Light
bugjam
Guests online: 133
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 MWS  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.052 sec.