Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
File I/O works on CP/M #19
Merged
Conversation
…en't done the array-index-type stuff yet, so array indices must now always be intptrs. Hmm.
…o work with and allows things like STORE4(stk, hl); mixed stack/register patterns must have the registers on the RHS.
registers get rearranged in loops --- e.g. swapping registers.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
This implements a whole bunch of stuff, including some register allocator improvements, allowing almost non-trivial code; enough that the CP/M file I/O library now works well enough to copy files.
The main compiler core issues run into:
turns out that mixing stacked and registered parameters in a rule is awkward. If the register is on the LHS and gets spilt to the stack, then this screws up the stack for the RHS. So, this is only allowed if the register is on the RHS. The only time this actually comes into play is STORE4 via a pointer, so change that so that the pointer is on the RHS.
the register allocator needs to handle loops in spills and reloads --- e.g. a->b, b->c, c->a. This is now broken by promoting something to a push/pop. A future improvement would be to use a register for this if one's available.