Virtue of converting ASM source to C?
Moderator: ZSNES Mods
Virtue of converting ASM source to C?
Since its beginning, the ZSNES project has employed massive amounts of highly optimized Intel assembler source. Although this source has been reputed to be the root of ZSNES' superior speed, I question its continued practicality.
If nothing else, the reams and reams of uncommented assembler source are a deterrent for hundreds of potential project aids whom are flabberghasted and intimidated by its complexity and vaguity. In an age when the performance of the ZSNES sources can be increased 15% by the NASM project, is the price in readability, stability, and barrier to entry worth the presumed benefit of performance superiority?
Even, the GUI, in all of its simplicity and irrelevance of performance, is coded in assembler. The ZSNES source is made opensource, but the question is begged, "who would bother?" Why should programmers be forced to wrestle with a gigantic assembler source tree that is barely diagrammed? Is it that important that ZSNES be regarded as a legend in its own time, that any who would presume to peruse the code in hopes of recognizing existing flaws and archaic structures would be dissuaded out of hand by the sheer challenge of parsing the source tree itself? Certainly not. If ZSNES is to be opensourced, then the ZSNES team has an obligation to opensource it right.
If nothing else, the reams and reams of uncommented assembler source are a deterrent for hundreds of potential project aids whom are flabberghasted and intimidated by its complexity and vaguity. In an age when the performance of the ZSNES sources can be increased 15% by the NASM project, is the price in readability, stability, and barrier to entry worth the presumed benefit of performance superiority?
Even, the GUI, in all of its simplicity and irrelevance of performance, is coded in assembler. The ZSNES source is made opensource, but the question is begged, "who would bother?" Why should programmers be forced to wrestle with a gigantic assembler source tree that is barely diagrammed? Is it that important that ZSNES be regarded as a legend in its own time, that any who would presume to peruse the code in hopes of recognizing existing flaws and archaic structures would be dissuaded out of hand by the sheer challenge of parsing the source tree itself? Certainly not. If ZSNES is to be opensourced, then the ZSNES team has an obligation to opensource it right.
Re: Virtue of converting ASM source to C?
You are not the only one. The developers are fully aware of it.lordgalbalan wrote:Since its beginning, the ZSNES project has employed massive amounts of highly optimized Intel assembler source. Although this source has been reputed to be the root of ZSNES' superior speed, I question its continued practicality.
I think it was needed back when computers were not as fast as today´s computers.lordgalbalan wrote:If nothing else, the reams and reams of uncommented assembler source are a deterrent for hundreds of potential project aids whom are flabberghasted and intimidated by its complexity and vaguity. In an age when the performance of the ZSNES sources can be increased 15% by the NASM project, is the price in readability, stability, and barrier to entry worth the presumed benefit of performance superiority?
Actually, they don´t. I think Nach said something about porting ZSNES's source to C/C++ but I am clueless about how far he got, or if he even started.lordgalbalan wrote:Even, the GUI, in all of its simplicity and irrelevance of performance, is coded in assembler. The ZSNES source is made opensource, but the question is begged, "who would bother?" Why should programmers be forced to wrestle with a gigantic assembler source tree that is barely diagrammed? Is it that important that ZSNES be regarded as a legend in its own time, that any who would presume to peruse the code in hopes of recognizing existing flaws and archaic structures would be dissuaded out of hand by the sheer challenge of parsing the source tree itself? Certainly not. If ZSNES is to be opensourced, then the ZSNES team has an obligation to opensource it right.
anewuser,
ps: Nach, how far did you get about porting the source code of ZSNES to C/C++?
If you want to see the results of an all-C emulator, try Snes9x. It's a great emulator, and portable, too. But I think you'll find a good number of people on the ZSNES boards still emulating on 200-500 MHz processors.
ZSNES isn't going all-C anytime this decade, although there are efforts to do so with the GUI code.
ZSNES isn't going all-C anytime this decade, although there are efforts to do so with the GUI code.
Last edited by DataPath on Sun Oct 03, 2004 4:55 pm, edited 1 time in total.
-
- Romhacking God
- Posts: 922
- Joined: Wed Jul 28, 2004 11:27 pm
- Contact:
We discussed this recently in another topic which slips my mind at this time.
Most people are in agreement that ZSNES's source code has lack of commenting and questionable organization.
The design choice of using assembly was a very good one at ZSNES's concepton. Remember, this was many years ago now.
The problem is what to do about it now. Porting ZSNES to C is like creating an entirely new emulator. That's why current plans only really call for porting a few things such as the GUI.
If you try and port the entire source to C, you are in fact creating an entirely new emulator. That would be an awful lot of work to start a new C based emulator and get it to match what ZSNES is now in terms of accuracy and compatibility and features. No one really wants to spend several years on that project, thus it's continued on in it's current form.
I completely agree that the source code now deters many prospective helpers and that's a problem, but there doesn't seem to be any easy solution in my eyes.
Most people are in agreement that ZSNES's source code has lack of commenting and questionable organization.
The design choice of using assembly was a very good one at ZSNES's concepton. Remember, this was many years ago now.
The problem is what to do about it now. Porting ZSNES to C is like creating an entirely new emulator. That's why current plans only really call for porting a few things such as the GUI.
If you try and port the entire source to C, you are in fact creating an entirely new emulator. That would be an awful lot of work to start a new C based emulator and get it to match what ZSNES is now in terms of accuracy and compatibility and features. No one really wants to spend several years on that project, thus it's continued on in it's current form.
I completely agree that the source code now deters many prospective helpers and that's a problem, but there doesn't seem to be any easy solution in my eyes.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
Nightcrawler is correct. You shouldn't even suggest converting all or most of ZSNES to C; it's an unfathomable amount of work. It would indeed likely be significantly easier to write an emulator in C from scratch, simply because then it would not be necessary to interpret the existing source, establish new variable names, shift to the functional appoach, re-optimize the code, and all the other variety of tasks that comes about changing between two dissimilar programming languages.
Sure, you could use inline assembly to make the conversion easier at first and more of a step-wise process, but that can't override the fact that ZSNES is a huge program. A few individuals simply cannot turn around years upon years of work in any reasonable amount of time.
So unless you've got a team of programmers fluent in x86 and C ready at your disposal, it's best not to take such an ideological solution to a practical problem.
I find this comment disconcerting:
The fact that the source is unreadable to any group of individuals is unconnected with the fact that ZSNES is open source, so don't correlate the two. There are people out there who know the language and can use it effectively. Developers should not be forced to shift to the language which the most users are developing with or know how to use...that's nonsense. If that were the case, everyone would be forced to use Java [see the TIOBE Programming Community (TPC) Index for January 2001 to March 2004].
Sure, you could use inline assembly to make the conversion easier at first and more of a step-wise process, but that can't override the fact that ZSNES is a huge program. A few individuals simply cannot turn around years upon years of work in any reasonable amount of time.
So unless you've got a team of programmers fluent in x86 and C ready at your disposal, it's best not to take such an ideological solution to a practical problem.
I find this comment disconcerting:
Open source is about freedom. The author(s) of an open source program has no obligation to code it in any particular language. Nor does the program need to be portable or run outside any given intended environment.Certainly not. If ZSNES is to be opensourced, then the ZSNES team has an obligation to opensource it right.
The fact that the source is unreadable to any group of individuals is unconnected with the fact that ZSNES is open source, so don't correlate the two. There are people out there who know the language and can use it effectively. Developers should not be forced to shift to the language which the most users are developing with or know how to use...that's nonsense. If that were the case, everyone would be forced to use Java [see the TIOBE Programming Community (TPC) Index for January 2001 to March 2004].
-
- Devil's Advocate
- Posts: 2293
- Joined: Mon Aug 02, 2004 7:51 pm
- Location: Hmo. Son.
Kagerato speaks the truth. I think there is a cookie cutter answer for this... "If you want to, you can do it yourself." I know next to nothin' about programing languages, but if there is something I know is that converting ASM to C is alot of work, if you can spend that time and effort, you are welcome to try.
*Sometimes I edit my posts just to correct mistakes.
here's my opinion:
zsnes is cool and fast, and feels really solid
snes9x is a tad slower, but more compatible, more acurate, but has a flimsy gui
if you took zsnes's gui and input features, then transplanted it onto snes9x, then you'd have a really sweet emulator, written in C.
I don't see why you'd convert zsnes into C, when there's already a better emulator written in C. tell me if I'm wrong, but I'm under the impression that snes9x IS a better emulator, even though I don't use it.
zsnes is cool and fast, and feels really solid
snes9x is a tad slower, but more compatible, more acurate, but has a flimsy gui
if you took zsnes's gui and input features, then transplanted it onto snes9x, then you'd have a really sweet emulator, written in C.
I don't see why you'd convert zsnes into C, when there's already a better emulator written in C. tell me if I'm wrong, but I'm under the impression that snes9x IS a better emulator, even though I don't use it.
[url=http://www.alexchiu.com/affiliates/clickthru.cgi?id=phonymike]ultimate immortality[/url]
[url=http://www.sloganizer.net/en/][img]http://www.sloganizer.net/en/image,zsnes,white,purple.png[/img][/url]
[url=http://www.sloganizer.net/en/][img]http://www.sloganizer.net/en/image,zsnes,white,purple.png[/img][/url]
-
- Hero of Time
- Posts: 2646
- Joined: Fri Jul 30, 2004 2:49 am
- Location: In front of the monitor
- Contact:
I heard ZSNES has the better sound, but I'm not so sure.phonymike wrote:here's my opinion:
zsnes is cool and fast, and feels really solid
snes9x is a tad slower, but more compatible, more acurate, but has a flimsy gui
if you took zsnes's gui and input features, then transplanted it onto snes9x, then you'd have a really sweet emulator, written in C.
I don't see why you'd convert zsnes into C, when there's already a better emulator written in C. tell me if I'm wrong, but I'm under the impression that snes9x IS a better emulator, even though I don't use it.
Just so you know - currently the GUI in assembler is about 600Kb of source code text.
Imagine translating 300-pages book from English to... whatever.
And translating it in a function-to-function way doesn't make sense - it hurts even to think about rewriting all that scrollbar-handling, cursor-blinking stuff.
There are some cross-platform interface packages exists, but do they support DOS? I don't think so.
MaxSt.
Imagine translating 300-pages book from English to... whatever.
And translating it in a function-to-function way doesn't make sense - it hurts even to think about rewriting all that scrollbar-handling, cursor-blinking stuff.
There are some cross-platform interface packages exists, but do they support DOS? I don't think so.
MaxSt.
-
- I know where you live.
- Posts: 148
- Joined: Thu Aug 19, 2004 4:51 am
SNES9x has had sound issues since the stoneage.snkcube wrote:I heard ZSNES has the better sound, but I'm not so sure.
FireKnight:I'm pretty sure a 1KG 24k gold brick costs less than that.
phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin.
I smell spray paint.
phonymike: well the same amount of raw metals used in a car costs a fraction of the price of a new car idiot. I'm gonna take away your posting privileges and replace them with my balls on your chin.
I smell spray paint.
Oh, I know....MaxSt wrote:Just so you know - currently the GUI in assembler is about 600Kb of source code text.
It's never fun, but it pays off in the end. No one said it had to be done overnight. I'm not above helping at those points whereat my skill will allow.Imagine translating 300-pages book from English to... whatever.
Some things are best left to ASM. But not all. Besides, scrollbars aren't that difficult to program in higher level languages. Have you been keeping track of your formulae?And translating it in a function-to-function way doesn't make sense - it hurts even to think about rewriting all that scrollbar-handling, cursor-blinking stuff.
There are some cross-platform interface packages exists, but do they support DOS? I don't think so.
-
- Romhacking God
- Posts: 922
- Joined: Wed Jul 28, 2004 11:27 pm
- Contact:
That's JUST the GUI. Do you really understand how much code is there? I consider myself to be very proficient in assembly and I would not not in a million years want to go through EVERY line of code in the source and convert it. That's insane.lordgalbalan wrote:Oh, I know....MaxSt wrote:Just so you know - currently the GUI in assembler is about 600Kb of source code text.
With today's SNES hardware knowledge, you could create the *basics* of a new emulator in a few months if not less.
After a few months of trying to port ZSNES.. you're most likely to have next to nothing to show for it yet.
So, why would someone choose to port when they can start anew and not run into several of the shortcomings and problems of ZSNES?
It doesn't really pay off in the end. If your goal is to faithfully reproduce ZSNES in C. At the end of your several year task, you're left with ZSNES again.It's never fun, but it pays off in the end. No one said it had to be done overnight. I'm not above helping at those points whereat my skill will allow.Imagine translating 300-pages book from English to... whatever.
If I were going to spend several years on an emulator. I would write it from scratch in C like it was mean to be written in C and overcome some of the issues ZSNES currently has. ZSNES isn't perfect you know.
I don't think you've actually LOOKED at the source. No one said programming a scrollbar was hard. It's interpreting and porting the existing ZSNES source.Some things are best left to ASM. But not all. Besides, scrollbars aren't that difficult to program in higher level languages. Have you been keeping track of your formulae?And translating it in a function-to-function way doesn't make sense - it hurts even to think about rewriting all that scrollbar-handling, cursor-blinking stuff.
There are some cross-platform interface packages exists, but do they support DOS? I don't think so.
You go look at it and you tell me where the code is for all the scrollbars. Then you should have a better understanding of what we're talking about.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
No, it's not. If you'd do the translation in a function-to-function way you'll simply get C mess instead of current ASM mess. If would not be easier to modify such code - adding a new selection box with a scrollbar would take a couple of days, if you're lucky.lordgalbalan wrote:It's never fun, but it pays off in the end.
GUI code is too interconnected. Function for drawing the scrollbar is in one source file, handling the mouse - in another, handling the keyboard - in a third. And those input handling functions are used in many other places... And it's not just functions, it's also lots of data being stored in global variables.Some things are best left to ASM. But not all. Besides, scrollbars aren't that difficult to program in higher level languages.
Easier to write a new GUI from scratch.
MaxSt.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
Re: Virtue of converting ASM source to C?
I only planned to port a few sections to C, like init.asm. If you look at initc.c, you'll see quite a bit has been ported since v1.36.anewuser wrote: ps: Nach, how far did you get about porting the source code of ZSNES to C/C++?
I currently write all non core emulation stuff in C unless it really makes a lot more sense to do it in asm.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
That's definitely the way to go. By writing the additional/new code in C, eventually a large chunk of the emulator will be designed in it. It might take twenty years, but it will eventually show results.
The CPU core and the more intensive graphics filters are best left written in x86 for a long time, I think.
The CPU core and the more intensive graphics filters are best left written in x86 for a long time, I think.
-
- Dark Wind
- Posts: 1271
- Joined: Thu Jul 29, 2004 8:58 pm
- Location: Texas
- Contact:
By then, Super Sleuth or something else will be 100% cycle accurate and have more features than zSNES has now.Kagerato wrote:It might take twenty years, but it will eventually show results.
I now see that being fluent in x86 assembler is only the first of many things I would have to learn to convert zSNES to C.
This talk has made me wonder, if zSNES is so convoluted, why not just start a new emulator? At the very least, why not rip out the emulation core and use something like the ScummVM GUI code?
[u][url=http://bash.org/?577451]#577451[/url][/u]
because no single snes emulator team has enough people to properly start from scratch.
if everyone decided to start a new one from scratch, designing the thing could take six months to a year before any coding gets done on it.
and the vast masses of snes emu users wouldn't care beyond when the next version is coming out.
if everyone decided to start a new one from scratch, designing the thing could take six months to a year before any coding gets done on it.
and the vast masses of snes emu users wouldn't care beyond when the next version is coming out.
-
- Romhacking God
- Posts: 922
- Joined: Wed Jul 28, 2004 11:27 pm
- Contact:
Absolutely! That seems to be the best place to start in my opinion.MaxSt wrote:In fat chicks' metabolism.lordgalbalan wrote:Where should change be made?
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
If you believe it takes six months to a year to design an emulator for something that is already very well documented, then I've got a bridge to sell you in Nantucket.funkyass wrote:because no single snes emulator team has enough people to properly start from scratch.
if everyone decided to start a new one from scratch, designing the thing could take six months to a year before any coding gets done on it.
and the vast masses of snes emu users wouldn't care beyond when the next version is coming out.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
He probably agrees with you with a very well documented system, but when designing a good emulator for the SNES it will take a while.lordgalbalan wrote: If you believe it takes six months to a year to design an emulator for something that is already very well documented, then I've got a bridge to sell you in Nantucket.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding