Allows bit 1 of R15 to be set in ARM mode.
The updated LDM/STM implementations are functionally identical to the
previous versions, but are significantly shorter and require less
special-casing.
Fixed an issue where an undefined opcode was being treated as an
unconditional branch in Thumb mode, and added a destination register
field to ARM mode BX instructions.
It's already expected that nall/main.hpp will only be included in a
single file, so we may as well define main at the same time. This allows
the console/Windows subsystem distinction to be controlled on a
per-target basis instead of being compiled into nall.
Targets that should always build as console applications now set a
CONSOLE variable in their CMakeLists.txt, overriding the cache variable
of the same name. The remaining targets can still be controlled at
configure time by passing -DCONSOLE=1, which will compile everything as
a console application.
Linking was failing under MinGW gcc because of a link order issue
between `libares` and `mingw32`. Establishing a direct link relationship
between `desktop-ui` and `mingw32` means that our `WinMain` definition
will not be discarded by `ld` before it's needed.
We also here add a Linux gcc runner and a Windows gcc runner; these do
not upload artifacts, but will allow us to detect build failures on CI.
At the moment, gcc support in general under CMake will still rougher
edges than clang or MSVC support, but it is intended that building with
`gcc` and `ld` should always at least work, even if `clang` remains
recommended and achieves superior performance.
This PR also adds a warning in the N64 core to acknowledge
https://github.com/ares-emulator/ares/issues/1737 until that issue can
be fixed.
Co-authored-by: John Tur <[email protected]>
This PR introduces a new CMake-based build system for ares.
Broadly, the goals of this build system are to:
* Modernize the build process somewhat, and make ares more approachable
for new developers
* Improve ares's dependency handling
* Expand and standardize platform/compiler/architecture support for ares
* Improve project code quality
* Improve build performance
* Lay groundwork for easier support of more platforms in the future
There are a few notable changes that this PR brings about. Briefly:
* Dynamic dependencies (librashader, MoltenVK, SDL, slang-shaders) are
no longer built in-tree
* Build system generation and building now take place as two separate
steps
Other notes:
* The legacy build system is deprecated, but is planned to still
function until such time as it is removed in a later PR
# New Features
* ares can now generate projects for Xcode and Visual Studio 17 2022.
Xcode is the recommended generator on macOS, supporting universal
binaries, advanced profiling and GPU debugging. Visual Studio projects
can be configured with either Clang-CL or MSVC, and may be generated for
either x86_64 or arm64.
* On macOS and Windows, dynamic dependencies are now built by
[ares-deps](https://github.com/jcm93/ares-deps) and fetched at
configure-time. This is to reduce build requirements for development,
define explicit versioning for dependencies, reduce build times
generally, and streamline CI workflows.
* Builds can now be configured through the default Windows command line
rather than requiring an MSYS2/MinGW shell.
* Ccache is also now universally supported to improve build performance.
Compile times should be further reduced with the addition of
precompilation of certain headers.
* A variety of other build system generators are now supported on all
platforms, including multi-configuration Ninja and applicable types of
Makefiles.
* Compiler diagnostic flags with clang have been standardized across all
platforms where possible[^1]. Currently, diagnostic flags have rough
parity with the old build system, but one goal of the new build system
is to introduce more strict compiler settings, to eliminate certain
classes of bugs and generally increase code quality.
# Supported Platforms
ARM64 and x86_64 architectures are officially supported across macOS,
Windows, Linux, and BSD[^1]. clang, Clang-CL, gcc, and MSVC are all
supported on applicable platforms. MSYS2/MinGW is supported along with
configuration and builds via the default Windows shell.
32-bit builds have not been tested.
# Current Status
Builds across all three of macOS, Windows, Linux, and BSD are generally
expected to work. Detailed build instructions can be found on the new
[ares wiki](https://github.com/ares-emulator/ares/wiki). CI workflows
are present and implemented but are still a work in progress. More
complete documentation is also a work in progress.
#### macOS
* Xcode, Ninja, Ninja Multi-Config, and Makefile generators are
functional
* Unlike Windows, multi-architecture builds are supported; pass
`-DCMAKE_OSX_ARCHITECTURES` as appropriate.
* Builds should generate a fully functional and relocatable app bundle
within the build directory, with relative rpaths; `install` rules are
placeholders.
#### Windows
* Visual Studio 17 2022, Ninja, Ninja Multi-Config, and Makefile
generators are functional
* Only single-architecture builds are currently supported
* Similarly to macOS, the build step generates a fully functional and
relocatable rundir with placeholder `install` commands.
#### Linux / BSD
* Unlike on macOS and Windows, it is required that the developer have
packages installed for libraries ares links against. A list of required
and optional libraries is found in the README.
* Build will output to a staging directory `rundir`; ares only uses
system libraries so this rundir should be fully relocatable
* `install` will perform a standard installation as CMake deems
appropriate for your distribution; you may pass the `--prefix` argument
as needed
* Maintainers may package as appropriate; a new Flatpak may be created
as part of this process, but has not yet
> [!IMPORTANT]
> These tasks should be completed before this PR moves out of the draft
state:
>
> * ~~CI workflows~~ - incomplete
> * ~~BSD support~~
> * ~~Windows SDL added to ares-deps~~
> * ~~ares-deps should probably be migrated to the ares-emulator
organization~~
> * More documentation
> * Miscellaneous cleanup, fixing issues found in testing, incorporating
general feedback
Nevertheless, now that builds are functioning on all three platforms, I
wanted to get this PR out there in a draft state to solicit testing and
feedback, as well as to give Linux package maintainers a head start in
terms of packaging.
> [!NOTE]
> While the PR is in a draft state, there may be breaking changes,
things may temporarily stop functioning, commits may be squashed, etc.
Thank you for testing and please report any issues you encounter!
* More detailed documentation on the internals of the build system is
available
[here](https://github.com/jcm93/ares/blob/cmake/cmake/README.md).
### Miscellaneous changes/points
* .gitignore is reorganized
* [gersemi](https://github.com/BlankSpruce/gersemi) is used for CMake
formatting, hence the presence of a `.gersemirc` file
* SDL on Windows is now a dynamic dependency.
* macOS asset files are reworked into .xcassets archives
* new macOS local build script introduced
* CI will include debug symbols for easier crash debugging
[^1]: Indicates something that might not be finished yet, or is subject
to change
---------
Co-authored-by: invertego <[email protected]>
Co-authored-by: Stefan Schlosser <[email protected]>
Co-authored-by: John Tur <[email protected]>
This implementation was based on our Z80 implementation and as such, has the following quirks:
1. Z80 style opcode mnemonics rather than intel style
2. Has an internal WZ register than a real 8080 lacks
3. May not have fully accurate timing
Despite this, it passes every test in this harness and is correctly detected by CPUTEST.COM as an 8080 rather than a Z80.
The remaining quirks can be addressed as needed
ZengGengSen