Implemented svcs GetResourceLimit, GetResourceLimitCurrentValues and GetResourceLimitLimitValues.
Note that the resource limits do not currently keep track of used objects, since we have no way to distinguish between an object created by the application, and an object created by some HLE module once we're inside Kernel::T::Create.
memory.cpp/h contains definitions related to acessing memory and
configuring the address space
mem_map.cpp/h contains higher-level definitions related to configuring
the address space accoording to the kernel and allocating memory.
It provided a large increase in complexity of the logging system while
having a negligible performance impact: the usage patterns of the ring
buffer meant that each log contended with the logging thread, causing
it to effectively act as a synchronous extra buffering.
Also removed some broken code related to filtering of subclasses which
was broken since it was introduced. (Which means no one ever used that
feature anyway, since, 8 months later, no one ever complained.)
There's no other coprocessor outside the VFP (which has its own VMOV variants) in which the MPCore can send/retrieve data from.
Stubbed so citra won't crash and burn on the odd chance someone actually tries to use these.
@neobrain, could you confirm that this is correct?
It's been tested with various different games and fixes different textures, including in Animal Crossing, Kirby Triple Deluxe, and SMB3D.
This works around crashes related to GSP/HID/etc. shared memory blocks
having garbage values. The proper fix requires proper management of
mapped memory blocks in the process.
When the macro was introduced in 326ec51261
it wasn't noticed that it conflicted in name with a heavily used macro
inside of dyncom. This causes some compiler warnings. Since it's only
lightly used, it was opted to simply remove the new macro.
Subv