ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/nall/stdint.hpp

66 lines
2.0 KiB
C++
Raw Normal View History

Update to 20160106 OS X Preview for Developers release. byuu says: New update. Most of the work today went into eliminating hiro::Image from all objects in all ports, replacing with nall::image. That took an eternity. Changelog: - fixed crashing bug when loading games [thanks endrift!!] - toggling "show status bar" option adjusts window geometry (not supposed to recenter the window, though) - button sizes improved; icon-only button icons no longer being cut off
2016-01-07 08:14:33 +00:00
#pragma once
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
#if defined(_MSC_VER)
typedef signed char int8_t;
typedef signed short int16_t;
typedef signed int int32_t;
typedef signed long long int64_t;
typedef int64_t intmax_t;
#if defined(_WIN64)
typedef int64_t intptr_t;
#else
typedef int32_t intptr_t;
#endif
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;
typedef uint64_t uintmax_t;
#if defined(_WIN64)
typedef uint64_t uintptr_t;
#else
typedef uint32_t uintptr_t;
#endif
#else
#include <stdint.h>
#endif
Update to v101 release. byuu says (in the public announcement): Not a large changelog this time, sorry. This release is mostly to fix the SA-1 issue, and to get some real-world testing of the new scheduler model. Most of the work in the past month has gone into writing a 68000 CPU core; yet it's still only about half-way finished. Changelog (since the previous release): - fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up screen) - new scheduler for all emulator cores (precision of 2^-127) - icarus database adds nine new SNES games - added Input/Frequency to settings file (allows simulation of latency) byuu says (in the WIP forum): Changelog: - in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7 precision in the worst case) - nearly ten times the precision of an attosecond - in 64-bit mode, Thread uses uint128\_t with 2^-127 time units (10^-26 precision in the worst case) - far more accurate than yoctoseconds; almost closing in on planck time Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly fine; but there was no speed penalty whatsoever for using uint128\_t in 64-bit mode, so why not?
2016-08-08 10:04:15 +00:00
//note: (u)intmax actually mean it: use as many bits as is possible
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
#if defined(__SIZEOF_INT128__)
using int128_t = signed __int128;
using uint128_t = unsigned __int128;
Update to v101 release. byuu says (in the public announcement): Not a large changelog this time, sorry. This release is mostly to fix the SA-1 issue, and to get some real-world testing of the new scheduler model. Most of the work in the past month has gone into writing a 68000 CPU core; yet it's still only about half-way finished. Changelog (since the previous release): - fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up screen) - new scheduler for all emulator cores (precision of 2^-127) - icarus database adds nine new SNES games - added Input/Frequency to settings file (allows simulation of latency) byuu says (in the WIP forum): Changelog: - in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7 precision in the worst case) - nearly ten times the precision of an attosecond - in 64-bit mode, Thread uses uint128\_t with 2^-127 time units (10^-26 precision in the worst case) - far more accurate than yoctoseconds; almost closing in on planck time Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly fine; but there was no speed penalty whatsoever for using uint128\_t in 64-bit mode, so why not?
2016-08-08 10:04:15 +00:00
Update to v101r02 release. byuu says: Changelog: - Emulator: use `(uintmax)-1 >> 1` for the units of time - MD: implemented 13 new 68K instructions (basically all of the remaining easy ones); 21 remain - nall: replaced `(u)intmax_t` (64-bit) with *actual* `(u)intmax` type (128-bit where available) - this extends to everything: atoi, string, etc. You can even print 128-bit variables if you like 22,552 opcodes still don't exist in the 68K map. Looking like quite a few entries will be blank once I finish.
2016-08-09 11:07:18 +00:00
#define INTMAX_BITS 128
Update to v101 release. byuu says (in the public announcement): Not a large changelog this time, sorry. This release is mostly to fix the SA-1 issue, and to get some real-world testing of the new scheduler model. Most of the work in the past month has gone into writing a 68000 CPU core; yet it's still only about half-way finished. Changelog (since the previous release): - fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up screen) - new scheduler for all emulator cores (precision of 2^-127) - icarus database adds nine new SNES games - added Input/Frequency to settings file (allows simulation of latency) byuu says (in the WIP forum): Changelog: - in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7 precision in the worst case) - nearly ten times the precision of an attosecond - in 64-bit mode, Thread uses uint128\_t with 2^-127 time units (10^-26 precision in the worst case) - far more accurate than yoctoseconds; almost closing in on planck time Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly fine; but there was no speed penalty whatsoever for using uint128\_t in 64-bit mode, so why not?
2016-08-08 10:04:15 +00:00
using intmax = int128_t;
using uintmax = uint128_t;
#else
Update to v101r02 release. byuu says: Changelog: - Emulator: use `(uintmax)-1 >> 1` for the units of time - MD: implemented 13 new 68K instructions (basically all of the remaining easy ones); 21 remain - nall: replaced `(u)intmax_t` (64-bit) with *actual* `(u)intmax` type (128-bit where available) - this extends to everything: atoi, string, etc. You can even print 128-bit variables if you like 22,552 opcodes still don't exist in the 68K map. Looking like quite a few entries will be blank once I finish.
2016-08-09 11:07:18 +00:00
#define INTMAX_BITS 64
Update to v101 release. byuu says (in the public announcement): Not a large changelog this time, sorry. This release is mostly to fix the SA-1 issue, and to get some real-world testing of the new scheduler model. Most of the work in the past month has gone into writing a 68000 CPU core; yet it's still only about half-way finished. Changelog (since the previous release): - fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up screen) - new scheduler for all emulator cores (precision of 2^-127) - icarus database adds nine new SNES games - added Input/Frequency to settings file (allows simulation of latency) byuu says (in the WIP forum): Changelog: - in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7 precision in the worst case) - nearly ten times the precision of an attosecond - in 64-bit mode, Thread uses uint128\_t with 2^-127 time units (10^-26 precision in the worst case) - far more accurate than yoctoseconds; almost closing in on planck time Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly fine; but there was no speed penalty whatsoever for using uint128\_t in 64-bit mode, so why not?
2016-08-08 10:04:15 +00:00
using intmax = intmax_t;
using uintmax = uintmax_t;
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
#endif
Update to v101 release. byuu says (in the public announcement): Not a large changelog this time, sorry. This release is mostly to fix the SA-1 issue, and to get some real-world testing of the new scheduler model. Most of the work in the past month has gone into writing a 68000 CPU core; yet it's still only about half-way finished. Changelog (since the previous release): - fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up screen) - new scheduler for all emulator cores (precision of 2^-127) - icarus database adds nine new SNES games - added Input/Frequency to settings file (allows simulation of latency) byuu says (in the WIP forum): Changelog: - in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7 precision in the worst case) - nearly ten times the precision of an attosecond - in 64-bit mode, Thread uses uint128\_t with 2^-127 time units (10^-26 precision in the worst case) - far more accurate than yoctoseconds; almost closing in on planck time Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly fine; but there was no speed penalty whatsoever for using uint128\_t in 64-bit mode, so why not?
2016-08-08 10:04:15 +00:00
using intptr = intptr_t;
using uintptr = uintptr_t;
Update to v095r10 release. byuu says: Changelog: - int_t<bits> replaced with Integer<bits> - uint_t<bits> replaced with Natural<bits> - fixed "Synchronize Audio" menu option that broke recently - all of sfc/performance ported to "auto function() -> return;" syntax With this WIP, all of higan is finally ported over to the new function declaration syntax. Thank the gods. There's still going to be periodic disruption for diffs from porting over signed->int, unsigned->uint, and whatever we come up with for the new Natural<> and Integer<> classes. But the worst of it's behind us now.
2015-12-06 21:11:41 +00:00
using float32_t = float;
using float64_t = double;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
//note: long double size is not reliable across platforms
//using float80_t = long double;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v092r08 release. byuu says: Changelog: - fixed cartridge load window focus on Windows - lots of updates to nall, ruby and phoenix - ethos and Emulator::Interface updated from "foo &bar" to "foo& bar" syntax (work-in-progress) Before I had mixed the two ways to declare variables/arguments all over the place, so the goal is to unify them all for consistency. So the changelog for this release will be massive (750KB >.>) due to the syntax change. Yeah, that's what I spent the last three days working on ...
2013-05-02 11:25:45 +00:00
static_assert(sizeof(int8_t) == 1, "int8_t is not of the correct size" );
static_assert(sizeof(int16_t) == 2, "int16_t is not of the correct size");
static_assert(sizeof(int32_t) == 4, "int32_t is not of the correct size");
static_assert(sizeof(int64_t) == 8, "int64_t is not of the correct size");
static_assert(sizeof(uint8_t) == 1, "int8_t is not of the correct size" );
static_assert(sizeof(uint16_t) == 2, "int16_t is not of the correct size");
static_assert(sizeof(uint32_t) == 4, "int32_t is not of the correct size");
static_assert(sizeof(uint64_t) == 8, "int64_t is not of the correct size");
Update to v095r10 release. byuu says: Changelog: - int_t<bits> replaced with Integer<bits> - uint_t<bits> replaced with Natural<bits> - fixed "Synchronize Audio" menu option that broke recently - all of sfc/performance ported to "auto function() -> return;" syntax With this WIP, all of higan is finally ported over to the new function declaration syntax. Thank the gods. There's still going to be periodic disruption for diffs from porting over signed->int, unsigned->uint, and whatever we come up with for the new Natural<> and Integer<> classes. But the worst of it's behind us now.
2015-12-06 21:11:41 +00:00
static_assert(sizeof(float) >= 4, "float32_t is not of the correct size");
static_assert(sizeof(double) >= 8, "float64_t is not of the correct size");
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
//static_assert(sizeof(long double) >= 10, "float80_t is not of the correct size");
Update to v095r07 release. byuu says: Changelog: - entire GBA core ported to auto function() -> return; syntax - fixed GBA BLDY bug that was causing flickering in a few games - replaced nall/config usage with nall/string/markup/node - this merges all configuration files to a unified settings.bml file - added "Ignore Manifests" option to the advanced setting tab - this lets you keep a manifest.bml for an older version of higan; if you want to do regression testing Be sure to remap your controller/hotkey inputs, and for SNES, choose "Gamepad" from "Controller Port 1" in the system menu. Otherwise you won't get any input. No need to blow away your old config files, unless you want to.
2015-11-16 08:38:05 +00:00
Update to 20160215 release. byuu says: Got it. Wow, that didn't hurt nearly as much as I thought it was going to. Dropped from 127.5fps to 123.5fps to use Natural/Integer for (u)int(8,16,32,64). That's totally worth the cost.
2016-02-16 09:27:55 +00:00
using uint = unsigned int;