amyipdev / xas-chip8-old Goto Github PK

The current implementation of data and pointer transformations is via the NumCast trait in num_traits. This works fine when translating between values that can fit in the target. However, there's one major issue: sometimes, data needs to be truncated into a pointer for which it can not fit. On C8/C8R, this can be seen when trying to place a pointer - which is a 12-bit value, and internally uses u16 - as a data argument (4-bit or 8-bit u4). Because all pointers are >= 0x200 due to rawbin's C8R offset (a product of the first 0x200 being reserved for the interpreter), all pointers are oversized.

There are two ways to fix this problem:

• Use num_traits::cast::AsPrimitive. This feels like the best way to go; it's an extremely inexpensive and easy-to-expand solution. Dealing with it, though, is almost impossible.
• Come up with a manual truncation solution of the form v & T::max(), where v is the value needing truncation, T is the target type, and max() is a function returning the maximum value the type supports, which will naturally have all available bits turned on. The issue with this comes back to getting the value of max() in the correct type, as a proper size change would need to occur.

We need a contributor code of conduct for libxas. Not necessarily relevant yet, but it's a good foundational item.

Self-explanatory

The two types:

1. n = val
2. .equ lbl val

Currently, rawbin

• Gets placeholders
• Resolves symbols
• Mutates the vec to fix the placeholders

Not only does this double the necessary steps, it also uses an expensive operation (the replacement). Instead, a tree of options should be made - Option<Vec> specifically, or some other variable-length array type. None indicates the need for a resolution, and can be paired with the individual archinstruction to be resolved. This should save a lot; best implementation of the tree is probably a linked list.

Because ArchInstruction is not inherently Sized - after all, it requires dynamic dispatch - it can not require Clone. Currently, all C8R instructions derive Clone, and this should not be the case. These derivations should be removed, as they are unnecessary.

It should theoretically not be too hard to add compatibility for Rust 2018. The main issue is importing some traits which are only in the 2021-and-onwards preludes. The question is, is doing this desirable? What do we really gain from using 2018 - compatibility with older toolchains? If so, why not even use 2015? I feel like this needs more thought/consideration, as it could be a development hamper. The effects on the MSRV are real though - 1.56.1 is pretty high. Hell, even Debian Stable doesn't use it. As such there's three potential options for consideration:

1. Do nothing, staying on 2021. This is the most likely path forward. After all, it does allow people who need 2018 to fall back to it with their own patches (see 3).
2. Move to 2018. Primary caveats already mentioned.
3. Have a separate branch on 2018. This seems like a fair option, and could be done by anyone needing 2018 on their own. Patches would be made on the 2021 (main) branch, and then as necessary, get pulled down to the 2018 branch with whatever changes are necessary.

Current list of desired utilities:

• Disassembler

FEATURE (separate project)

xasd would be a daemon to run a compilation server for libxas-based projects. Would have plugins for various compiler frontends and system linkers.

cxasd would be a CLI interface for xasd which could also monitor the status of foreign xasd servers.

gxasd would be a graphical (libadw?) version of cxasd.

A lot of things use fully-qualified paths, especially within BBU, when the traits are already imported by necessity. This should not happen. Common examples are SymConv and PtrSize.

Any unnecessary abstractions should be removed by 1.0. In particular, the focus of this should be, if possible, dismantling the LexOperation system.

This reflects that ArchInstruction is now used for both post-lexer macros and instructions. Fairly simple refactor, might be able to be done automatically. No documentation changes required.

When libxas is published on crates, there's a better way to do it:

• The main crate is still libxas, and has only stable releases
• However, there'll also be a libxas-testing crate, which gets RCs