5.9 KiB
5.9 KiB
libSceAmpr technical debt
Unknown function info
- AMPR WriteAddressFromCounterPairOnCompletion (libSceAmpr) - the pair of an even counter n is assumed to give counter n in the low 32 bits and n + 1 in the high 32 bits. Wait compare values, wait flush and counter index ranges follow the ampr_emu reimplementation; the flush is accepted and has no effect, as commands run in order
- AMPR command buffer offsets (libSceAmpr) - recording with a current offset greater than the bound memory size throws before calculating remaining capacity or writing a command. This validates the emulator's own command-buffer encoding; the console's response to a corrupted opaque buffer object is unknown.
- AMPR command sizes (libSceAmpr) - commands use the emulator's own encoding with an 8-byte header, so
Nop(n)takes 8 + 4n bytes where the console record is n dwords including its header (NopWithData(n): (n + 1) dwords). The measure functions agree with the appended sizes, but a title that pads to an exact offset or the end of the buffer withNop(remaining / 4)getsSCE_AMPR_ERROR_BUFFER_FULLor a shifted offset. The at-start flag of the_04_00writes is ignored; commands run in order, each after the previous one completes - APR map begin and end (libSceAmpr) - as in ampr_emu,
MapBegin/MapDirectBeginmap when they run andMapEndonly closes the region; while a region is open a second begin and every completion write returnEPERM, the at-start_04_00writes are accepted - AMPR markers (libSceAmpr) - signatures taken from the ampr_emu reimplementation, not confirmed on a title:
sceAmprCommandBufferSetMarkerWithColortakes the color by pointer, the push and measure variants by value. Colors are not recorded
Functional
- sceAmprAmmGetUsageStatsData (libSceAmpr) fills the caller-sized 24-byte statistics structure with 512 page-table pool entries, no allocated entries, a zero high watermark and ring idle flags 0x7, the constants of KytyPS5; they are not measured on a console, and the real call is a pass-through to
sceKernelMapperGetUsageStatsDataper drakmor/ampr_emu, which this port has no kernel-side counterpart for. - Dinkumware thread exports (libSceAmpr) follow the Dinkumware threads library shipped with Visual C++ 2013 (
cthread.c) and itsatomic.c, microsoft/STLcthread.cppand C11 Annex K, without console verification._Thrd_tis taken to be the guestpthread_t, as thestd::_Pad::_Launch(pthread**)export suggests:_Thrd_joinreturns_Thrd_error(4) whenpthread_joinfails and stores the thread's return value truncated toint._Thrd_join(32-bit store of the result, 0 or 4) and the spin lock (byte exchange loop, no yield) match that disassembly. The shared_ptr spin lock is one process-wide flag that yields while it spins.wcstombs_siswcsrtombs_swith a fresh conversion state, so*retvalexcludes the terminating null as in Annex K, not as in the Microsoft CRT, and_TRUNCATEhas no meaning. - _Cnd_signal, _Cnd_init_with_name (libSceAmpr) - take a pointer to the handle slot like the libc
_Cnd_*exports from #3079 and act on the same conditions._Cnd_signalwakes one waiter and returns_Thrd_success(0), as_Cnd_broadcastdoes; whether the console maps a failing internal signal to_Thrd_erroris not known. The signature_Cnd_init_with_name(_Cnd_t*, const char* name)is inferred from fpPS4ps4_mtx_internal.pas, where the PS4_Mtx_initis_Mtx_init_with_namewith the nameSceLibcI_Mtxand the name only reaches the pthread object; here it is_Cnd_initand the name, which may be null, is ignored. Neither is confirmed on a PS5libc.prx._Thrd_idstill throws: microsoft/STL returns anunsigned intthread id, but whether the PS5 returns thepthread_tor a kernel thread id, and at what width, is not known - std::_Pad (libSceAmpr) follows Dinkumware V6.00
thr/xthreadandthr/threadcall.cppof Visual C++ 2013 (crt.vc12f1d47126), without console verification. The pad is taken to be that header's class with the console's pointer handles: a vtable pointer whose first slot is the pure virtual_Go(), then_Cnd_tat 0x8,_Mtx_tat 0x10 andbool _Startedat 0x18, 32 bytes, the derived_LaunchPadtarget following it; the console's_Pad(const char*)and_Launch(const char*, pthread**)/_Launch(pthread_attr**, pthread**)overloads suggest named primitives and could mean another layout or vtable._Launchstarts the thread withpthread_createand default attributes (the console's_Thrd_startname, stack size and priority are unknown), its entry calls_Go()and returns the result as the exit code, and it does not run_Cnd_do_broadcast_at_thread_exit, which is absent here. A failing primitive throws the gueststd::system_errorthat_Throw_C_errorpicks for its code, and a failing thread start theresource_unavailable_try_againone of_Thrd_startX; anypthread_createerror counts, since the console's_Thrd_startresult is unknown. A null pad or thread slot throws