frederik
/
oscar64
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bump version number

This commit is contained in:
drmortalwombat 2025-06-15 14:27:49 +02:00
parent 4633631d7e
commit c7a53a5be6
5 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -4,7 +4,7 @@ Oscar64 is a C/C++ cross compiler running on a modern system (such as a Windows
The purpose of this compiler is to eliminate the need to write 6502 assembler code to achieve high code density and fast execution speed. It continues to improve with all the games, demos and tools written by it. It supports disk overlays and banked cartridges for larger projects.
The C64 executes 418 dhrystone V2.2 iteration per second, when compiled with Oscar64 and -O3 (which shows that the ancient dhrystone benchmark is no match to an optimizing compiler).
The C64 executes 442 dhrystone V2.2 iteration per second, when compiled with Oscar64 and -O3 (which shows that the ancient dhrystone benchmark is no match to an optimizing compiler).
[Full reference manual](oscar64.md)
[Additional samples and tutorials](https://github.com/drmortalwombat/OscarTutorials)

2
oscar64.md
View File

@ -28,7 +28,7 @@ In the end, it turned out that the native code is not only significantly faster
## Limits and Errors
There are still several open areas, but most targets have been reached. The current Dhrystone performance is 94 iterations per second with byte code (10993) and 405 iterations with native code (9173 Bytes). This clearly shows that Dhrystone is not a valid benchmark for optimizing compilers, because it puts the 6502 on par with a 4MHz 8088 or 68k, which it clearly is not.
There are still several open areas, but most targets have been reached. The current Dhrystone performance is 94 iterations per second with byte code (10993) and 442 iterations with native code (8952 Bytes). This clearly shows that Dhrystone is not a valid benchmark for optimizing compilers, because it puts the 6502 on par with a 4MHz 8088 or 68k, which it clearly is not.
### Language

2
oscar64/oscar64.cpp
View File

@ -76,7 +76,7 @@ int main2(int argc, const char** argv)
#else
strcpy(strProductName, "oscar64");
strcpy(strProductVersion, "1.31.260");
strcpy(strProductVersion, "1.31.261");
#ifdef __APPLE__
uint32_t length = sizeof(basePath);

8
oscar64/oscar64.rc
View File

@ -25,8 +25,8 @@ LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL
//
VS_VERSION_INFO VERSIONINFO
FILEVERSION 1,31,260,0
PRODUCTVERSION 1,31,260,0
FILEVERSION 1,31,261,0
PRODUCTVERSION 1,31,261,0
FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
FILEFLAGS 0x1L
@ -43,12 +43,12 @@ BEGIN
BEGIN
VALUE "CompanyName", "oscar64"
VALUE "FileDescription", "oscar64 compiler"
VALUE "FileVersion", "1.31.260.0"
VALUE "FileVersion", "1.31.261.0"
VALUE "InternalName", "oscar64.exe"
VALUE "LegalCopyright", "Copyright (C) 2021"
VALUE "OriginalFilename", "oscar64.exe"
VALUE "ProductName", "oscar64"
VALUE "ProductVersion", "1.31.260.0"
VALUE "ProductVersion", "1.31.261.0"
END
END
BLOCK "VarFileInfo"

6
oscar64setup/oscar64setup.vdproj
View File

@ -6310,15 +6310,15 @@
{
"Name" = "8:Microsoft Visual Studio"
"ProductName" = "8:oscar64"
"ProductCode" = "8:{AC5D51E8-FCED-40D8-950C-D7EEFD597215}"
"PackageCode" = "8:{34F40BDD-B555-4C84-80A6-A2F8B4128E9C}"
"ProductCode" = "8:{1B9A0E10-DEA6-4276-AC91-17782FE44D94}"
"PackageCode" = "8:{51BFE576-50D1-4F8F-AE7A-9FF07396F53D}"
"UpgradeCode" = "8:{9AB61EFF-ACAC-4079-9950-8D96615CD4EF}"
"AspNetVersion" = "8:2.0.50727.0"
"RestartWWWService" = "11:FALSE"
"RemovePreviousVersions" = "11:TRUE"
"DetectNewerInstalledVersion" = "11:TRUE"
"InstallAllUsers" = "11:FALSE"
"ProductVersion" = "8:1.31.260"
"ProductVersion" = "8:1.31.261"
"Manufacturer" = "8:oscar64"
"ARPHELPTELEPHONE" = "8:"
"ARPHELPLINK" = "8:"