| |
Sasq
Registered: Apr 2004
Posts: 155 |
Badass - New 6502 Assembler
The last couple of months I've created a new 6502 Assembler called bass (or Badass).
The basic idea is for it to be as advanced as Kickassembler, but with a less complex, more unified syntax.
And it also has unit tests in an internal emulator.
You can find it at https://github.com/sasq64/bass
I've started a tutorial here: http://apone.org/bass/part1.html
Here is an example C64 source http://apone.org/bass/example.asm.html |
|
... 106 posts hidden. Click here to view all posts....
|
| |
Raistlin
Registered: Mar 2007
Posts: 562 |
Sorry, I’m mixing my STA and LDA timings :-) |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Ok, well, thinking a bit further about it, this is one of the few things where a Turing-complete scripting language native to the assembler would come in handy. (Not much of a fan of that otherwise, one hammer vs. world made of nails and so.)
Something where stateful user code can do accounting and control emission of opcodes, etc. |
| |
Rex
Registered: Sep 2011
Posts: 14 |
That is a neat optimization Raistlin!
Another option would be marking some of the logic code blocks as independent to allow the merger to re-organize them to fill the available cycles with as much active code as possible.
One general need is probably the cycle-exact code merging. A solution for that should be able to fill cycle gaps in cycle-exact raster code. This requires the ability to keep track of cycle counts. A general solution should probably also support keeping track of (and handling) register usage. Smart optimizations like what you are proposing would also be nice.
Merging code and data in memory under constraints is probably a different use-case with different requirements. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11118 |
rearranging code in cycle exact code doesnt only require tracking cycle count... you also have to track where in the line you are and consider the dma setup cycles. sounds like fun =) |
| |
Raistlin
Registered: Mar 2007
Posts: 562 |
Just to throw another spanner into this already quite complex system...
Something else that I do on C++ side is that I have some "loose" setup things that need to be done .. so, for example, it's common to want to move the Sprite Y values down every 21 lines. Except of course it doesn't need to be on exact lines - it can be almost anywhere within the existing line of sprites - so you have ~20 raster lines where it could happen for every 21.
I effectively make that a low-importance task - but higher importance than the "slow" task (which is usually something like the blitting of the DYPP or circle scroll).
And... it's good to know what raster-line you're on at each point - when scrolling D800 data, or when updating bitmap data etc, it's good to know whether you're behind or ahead of the raster.
Coding all of this, and keeping within memory budgets, is quite a task ;-) |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Quoting RaistlinCoding all of this, and keeping within memory budgets, is quite a task ;-) Top Coders
1 Raistlin (9.8)
2 Graham (9.8)
3 Crossbow (9.8) That top spot don't come from nothin'. =) |
| |
map
Registered: Feb 2002
Posts: 27 |
Quoting Krill
But an open and generic tool for that would be nice, and possibly included with an actual assembler.
I totally agree that it would be nice to have such a tool. Maybe even nicer to have the possibility to combine it with the assembler of your choice instead of having it build into a certain assembler only. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Looks great from the first look! <3 |
| |
Krill
Registered: Apr 2002
Posts: 2845 |
Quoting mapI totally agree that it would be nice to have such a tool. Maybe even nicer to have the possibility to combine it with the assembler of your choice instead of having it build into a certain assembler only. That's a good point.
Another would be that it can take quite long to generate good solutions to the problem (which is quite often NP-complete or worse), and you'd want to keep intermediate artefacts for speedier rebuilds and retain some manual control over the process. Pretty similar to synthesised netlists in FPGA/PLD stuff. |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
So if you had something like this, how far would that get you? :
!delay <cycles>, <regs_to_preserve>
!merge <section1>, <secition2>, <max_cycles>
Where merge was allowed to insert any code in the delay "slots"
as long as registers where preserved ? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 - Next |
