-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
T-state counting #145
Comments
One of the first things I've done when I restarted writing assembly code in 2013 was to create a t-states counting library (it was very basic, but would be able to deal with the task as above). Unfortunately, since then I grew to recognize that a feature like this does not belong to assembler, or to be more precise, would be mostly useless in assembler, esp. for an assembler that attempts to be multiplatform, as sjasmplus. The reason for this is very simple:
All in all, if you want accurate timings, this a job for a good emulator for your platform. There are assemblers that can invoke emulators as part of their workflow (I know of at least one), but this is a very substantial commitment and redesign, which is difficult to justify here. |
I recently wrote a piece of code like that, but the durations are given in "NOPs" for the Amstrad CPC. By updating the arrays in the source you could get the T-States, I suppose : By the way, any advise on this code is welcome ;-)
There's a problem with this code : You can't use this value later in the code without raising warnings
this code produces the right opcodes (#3E #2 followed by 62 #00) but raises a lot of "warning: Label has different value in pass 3' |
the Lua script looks quite good (just incomplete with regards to IX/IY and bit instructions if I understand it correctly from quick read). I would probably define it as function during PASS1 and then just call it in PASS3 whenever needed to avoid all of this being defined/processed multiple times for each block. the problem with later use is unfortunately hard limit of the sjasmplus design, the code to assemble and thus addresses between second and third pass should be same, thus reading the code in third pass and adjusting by that is breaking this principle. If you really know what you are doing and you don't care about the warnings, you can still sometimes get what you asked for in the binary, but the "correct" way to do this would be to assemble these independently, first assemble to binary blob the inner part which will be aligned, then in new asm file and new assembling process incbin that... oh wait, that reads actual bytes still in pass3 .. hmm.. so you would have to read the file by lua io in each pass (or first pass) and calculate the T-states and then have the DUP padding fixed for every pass with same result. Or produce the inner code in first assembly and during its third pass generate the timing info and In other words this type of task is not a good-fit for sjasmplus, and there's no simple fix/improvement to get there. If you don't want to go there splitting the assembling into two, you can avoid some of those warnings by hard-padding the DUP block with like I think this nicely illustrates why it would be tricky to add it into sjasmplus, and to satisfy all possible use-cases, so I'm still not even considering that. I'm somewhat open to the idea of adding T-states printed into listing file (under some option), but not planning to do that in near future, and it would not help use cases like this, would just make manual counting a bit simpler. In my ideal world I would rather see more tools doing their part of work, like z88dk |
T-state counting similar to zmac.
Example of usage here
Example:
The text was updated successfully, but these errors were encountered: