Steem technical questions/problems

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Steem technical questions/problems

Postby Dio » Wed Dec 21, 2011 2:35 pm

I understand the mechanics of templates fairly well, thanks. I've even got to the point of using traits classes and getting very near to genuine TMP, although I still find that stuff a bit scary.

What I don't understand is why you would create such a template, what it achieves. To me it appears that you've wrapped a value type in a class that implements... a value type? What advantages does it have over just using the value type in the first place? Even if you plan to do template customisations to apply the various checks that you claim are an advantage (which would be an extraordinarily clumsy way of doing it, I'd have thought?), I don't see how this achieves anything in isolation, since the state of the device only makes sense in toto.

I am certain that a cleaner OO design would implement 'a DMA controller' and either the signals that come to and from it, or the operations that those signals convey, or some combination of the two. It needs to talk to a bus device, an FDC controller and the hard disk, and maybe a debugger, and nothing else.

That's real encapsulation and OOD. An object:
- knows and manages its state
- provides clear and absolutely minimal interfaces for it to talk to the rest of the system, and for the rest of the system to talk to it
- can implement its state management in any way it likes, and arbitrarily vary said implementation without affecting the rest of the system
- nothing in the rest of the system can interfere with this

And I can't see any use for overloaded operators in that, if you're trying to generate maintainable code :D .

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Wed Dec 21, 2011 5:08 pm

I am talking here of very basic usage of template far far away ... from template meta-programming...

Let me try to find the article that have read recently on the subject of accessors it probably explain better than me the structure I have used in the dma example
Sorry but my English is probably not so good. I will keep posted if I find it

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Wed Dec 21, 2011 5:28 pm

DrCoolZic wrote:I am talking here of very basic usage of template far far away ... from template meta-programming...

Let me try to find the article that have read recently on the subject of accessors it probably explain better than me the structure I have used in the dma example
Sorry but my English is probably not so good. I will keep posted if I find it

found it http://www.kirit.com/C%2B%2B%20killed%2 ... 0accessors

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Wed Dec 21, 2011 5:33 pm

Back to Steem questions.
I have pretty much located in Steem the code that is used to emulate the transfer part of the dma (io <-> memory)
Does anybody knows if Steem also includes some code to take care of the fact that when performing dma transfer the bus is granted to the dma and the cpu placed in hold. This has impact on cpu execution and I would like to know if this is taken in account in Steem and where would this be located?

!cube
Atari maniac
Atari maniac
Posts: 80
Joined: Thu Jun 14, 2007 6:37 am
Location: Vantaa, Finland
Contact:

Re: Steem technical questions/problems

Postby !cube » Fri Dec 23, 2011 7:49 am

DrCoolZic wrote:
DrCoolZic wrote:I am talking here of very basic usage of template far far away ... from template meta-programming...

Let me try to find the article that have read recently on the subject of accessors it probably explain better than me the structure I have used in the dma example
Sorry but my English is probably not so good. I will keep posted if I find it

found it http://www.kirit.com/C%2B%2B%20killed%2 ... 0accessors


I have to say that I don't agree with that article. I don't understand what benefits you could possibly get from replacing the 'get' and 'set' accessors with operator() overloads. This is the kind of C++ wanking that just makes me sick, using template meta-programming to create a new syntax for no purpose whatsoever.

More and more people are coming up with "clever" solutions to the most simple problems. In that article, the guy created a template class for what? Just so that he wouldn't need to use the "get" and "set" prefixes in his code and that the range check is encapsulated in the template class instead in the main class which has the longitude and latitude members. The purpose of C++ isn't to use all its features every time you do the most simplest thing but to get the job done.
Kludge power since 1976.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Steem technical questions/problems

Postby Dio » Fri Dec 23, 2011 9:28 am

DrCoolZic wrote:
DrCoolZic wrote:I am talking here of very basic usage of template far far away ... from template meta-programming...

Let me try to find the article that have read recently on the subject of accessors it probably explain better than me the structure I have used in the dma example
Sorry but my English is probably not so good. I will keep posted if I find it

found it http://www.kirit.com/C%2B%2B%20killed%2 ... 0accessors

As well as agreeing 100% with !cube's comments above - it's not a programming competition, you should do the clearest thing not the cleverest thing - I'm not sure I see the relevance of that example to the one you showed. That example shows classic type parameterisation of a value class.

I don't think you'll be writing any value classes for emulation though. Most of the classes will be state classes. In state classes, it's wise to avoid accessors and only supply functions implementing entire operations that manipulate the state, with a clear, well-defined, minimal interface.

Anyway, I've said enough on this topic.

User avatar
Steem Authors
Steem Developer
Steem Developer
Posts: 540
Joined: Tue Apr 30, 2002 10:34 pm
Location: UK
Contact:

Re: Steem technical questions/problems

Postby Steem Authors » Wed Dec 28, 2011 10:42 pm

Steem could certainly be better organised... more modules (>3) would be a good start.

When we wrote Steem we were more used to C and it uses some pretty basic and sometimes poor C techniques. Now we work mainly in Java and so the amount of globals/macros/casting is a bit horrifying to look back on!

We did look at starting to reorganise the code to be more OO but we gave up as it was too hard/tedious to keep it working with all these changes. C++ makes classes pretty painful with its insistence on header files.

We were concerned about performance... e.g. storing the memory location in a variable to be dereferenced from a class instance pointer adds another indirection to every memory access, which would be a significant drag. Also I would be nervous about compilers optimising away inline function calls as well as they process macros. but that concern might be out of date. Also when we were first writing Steem, Intel processors were about 400MHz!

UI components are already written as classes for both Windows and Linux builds. It's really the core emulation / chip components which could be better encapsulated... though just like in a real ST, they are not all entirely isolated from each other!

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Thu Dec 29, 2011 2:21 pm

Steem Authors wrote:Steem could certainly be better organised... more modules (>3) would be a good start.

If you want to have a look I have already reorganized Steem in a tree that I have published here viewtopic.php?f=94&t=22330
I am doing my development with Visual C++ and the original Steem organization was a pain as the different IDE browsers do not look into the included .cpp files.
So what I did was to modify the source so that the declarations are in .h and the definitions/implementation in .cpp (only did that on the Windows part leaving the work for Unix part to someone else). So now it is possible to search, look at call tree, all classes variables, etc. much more effectively. Actually this was not so difficult just time consuming (about 2 weeks).

When we wrote Steem we were more used to C and it uses some pretty basic and sometimes poor C techniques. Now we work mainly in Java and so the amount of globals/macros/casting is a bit horrifying to look back on!
While it is obvious that the code has been written in C (even if C++ syntax was used) this is still very well written code and very efficient (not to mention that I still consider Steem as the best Atari Emulator). I do not like macros but they are useful at time. The problem I have with them in Steem is that it is more difficult to follow the emulator execution in MS VC debugger... The only problem with the current code is that it is probably a bit more difficult for outsider to understand and modify the source.

We did look at starting to reorganise the code to be more OO but we gave up as it was too hard/tedious to keep it working with all these changes. C++ makes classes pretty painful with its insistence on header files.
I think that using OO for developing an emulator seems a good choice. Forget about what I have published above because as Dio and !cube have mentioned the model of the DMA that I have presented is totally wrong and not OO at all.
Just as an exercise I am currently analyzing what would be a proper OO model for the DMA. But may be I did not choose the right device because it looks like in the actual Steem code the DMA is not modeled as a separate entity. The behavior of the DMA seems in fact "included" mainly in the FDC model and only few global variables mention the DMA. I am a novice in emulation technique but from what I have seen it seems that usually emulators do not model the internal busses and therefore it is probably for performance reason that the DMA has been modeled as a separate object. However it would be possible to develop such model in order to get a more detail description (the DMA is stilling cycles to the CPU).

We were concerned about performance... e.g. storing the memory location in a variable to be dereferenced from a class instance pointer adds another indirection to every memory access, which would be a significant drag. Also I would be nervous about compilers optimising away inline function calls as well as they process macros. but that concern might be out of date. Also when we were first writing Steem, Intel processors were about 400MHz!
Of course I can understand that performance was probably critical at the time. I do not know for sure but I think that with current Intel processors power emulating a 68000 should be possible even if you have relatively less efficient code using some of the nice features of C++

UI components are already written as classes for both Windows and Linux builds. It's really the core emulation / chip components which could be better encapsulated... though just like in a real ST, they are not all entirely isolated from each other!
Yes the original gang of 4 in the ST does not separate the "functions" cleanly! so modelisation could be done either way: per component or per function.

User avatar
npomarede
Atari God
Atari God
Posts: 1241
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Steem technical questions/problems

Postby npomarede » Thu Dec 29, 2011 4:25 pm

DrCoolZic wrote: I think that using OO for developing an emulator seems a good choice. Forget about what I have published above because as Dio and !cube have mentioned the model of the DMA that I have presented is totally wrong and not OO at all.
Just as an exercise I am currently analyzing what would be a proper OO model for the DMA. But may be I did not choose the right device because it looks like in the actual Steem code the DMA is not modeled as a separate entity. The behavior of the DMA seems in fact "included" mainly in the FDC model and only few global variables mention the DMA. I am a novice in emulation technique but from what I have seen it seems that usually emulators do not model the internal busses and therefore it is probably for performance reason that the DMA has been modeled as a separate object. However it would be possible to develop such model in order to get a more detail description (the DMA is stilling cycles to the CPU).

Of course I can understand that performance was probably critical at the time. I do not know for sure but I think that with current Intel processors power emulating a 68000 should be possible even if you have relatively less efficient code using some of the nice features of C++


Hello

I don't want to start a debate / flame war on C vs C++, but in the case of hardware emulation, I don't see the benefit of C++ (the GUI case is different, many toolkit were made from the ground up to be easier to use in C++ ). Of course, everyone is free to choose the language he prefers the most and where he's the most efficient, but performance-wise, I don't think C++ has some "nice features" over C in that case. C++ has nice features for readibility, reusability, but optimisation-wise I don't see why it would give better asm code than some well written C code.
In my opinion, using OO for emulation is overkill, classes are not really used several times in several objects (you have 1 MFP, 1 shifter, 1 FDC, ... (OK, there're 2 ACIA :) ).
Some people might prefer calling object methods instead of a function with a pointer to the corresponding data structure, this is a "readibility" choice, but for an emulator, it won't change performance. Same for the classes, you can have the same result with a correctly designed C structure.

What I mean is not that C++ is useless, it's that in the case of the emulation the data you manipulate are rather "simple" (each hardware component is often unique, no inheritance or template to benefit from), so what really matters is to design the correct representation / inner working of each chip. Depending on the accuracy of the model you choose, this will directly impact the performance, but it's quite unlikely that C++ could give performance you wouldn't get from good C code.

As an example, MAME is written in C, and over the year it has evolved in a rather open model where it's quite easy to "plug" different cpu, audio chip, fdc, ... together to emulate a specific arcade board.

I think the goal of an emulator is to reach maximum accuracy with the best performance possible, rewritting Steem in C++ to reach this goal could be a necessary step if the people who want to improve Steem are more efficient with C++, but changing structures, operators, ... now from C to C++ just for the fun of rewriting it and in the hope others will continue later to work on Steem doesn't seem obvious to me (this is different from what Dio did, where he wrote Emu in C++ from the start).

Again, don't take offence from this, but after working on Hatari for a few years and other emulation projects before, I'm really convinced that the language is not the solution, it's just a tool ; some people might be more efficient with the C++ tool, other will prefer the C tool, but the real problem is to model each component (and especially the non documented behaviours in the FDC for example)

Nicolas

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Thu Dec 29, 2011 5:38 pm

Nicolas,
I totally agree with you: the language is not really important and most probably code written in C++ will be slower than code written in C especially if using some fancy features. But as you said the most important is to have a good project architecture and I think that using object oriented approach seems relatively natural for an emulator (at least from what I understand). There are a lot of OO designs that where done long long time ago in C before C++ existed (early X11 development is a good example) so yes language is not really an issue. There are even some specialized site and tools about how to enforce OO design using C (if interested I can provide pointers).

I also agree that it probably does not make any sense to "convert" Steem to be full OO using C++ fancy features.

Originally I started to look at Steem code to understand how difficult it would be to support IPF files in Steem (and may be in Hatari). As I said I had problem with the code organisation but I have solved the problem. I am still trying to modify the code so it is more easy for me to follow. For example removing some of the macros and maybe create some class to help grouping and encapsulate information, but probably nothing drastic. And of course this would be for me to play and I would not try to push this on the "official Steem tree".

I have been coding in C++ for quite sometimes but I am not familiar with emulators so I am currently in a learning phase and Steem seems a reasonable starting point. However I have been involved in Virtual component co-simulation using SystemC language and I can see a lot of similarity...

So many different definitions for simulation versus emulation I particulary like the one from Arun Parajuly
Arun Parajuli wrote:Emulation:
A system X is said to emulate another system Y if the behaviour of X is exactly the same as that of Y ( same out put for same input under similar conditions) but the mechanism to arrive at the output ( from the input) is different. Emulation is generally used when we don't exactly know the internal mechanism of the original system but are familiar with the input/output pattern . For example, neural networks may be used to emulate different systems. Neural networks are trained to produce the same output for the same input as that of the original system though the mechanism/procedure to generate the output are quite different.

Simulation:
A system X is said to simulate another system Y when the internal mechanism/procedures of X is a mathematical ( or any other) model known to best represent the actual mechanism of Y. Simulation is generally used when we have some mathematical models of the original system (Y) and want to know output for a given set of inputs. For example we may have a good mathematical model of effect of water temperature on the hurricane formation. We use that system to predict the nature of hurricanes for different water temperatures. It is to be noted that the result of simulation can sometimes be unverifiable. For example the hurricane pattern suggested by the simulator for water temperature equal to 50 degree Celsius will be difficult to verify because we may never encounter such situation.

Arun Parajuli - Jan 2006
Last edited by DrCoolZic on Thu Dec 29, 2011 8:03 pm, edited 1 time in total.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Thu Dec 29, 2011 6:27 pm

npomarede wrote:...
In my opinion, using OO for emulation is overkill, classes are not really used several times in several objects (you have 1 MFP, 1 shifter, 1 FDC, ... (OK, there're 2 ACIA :) ).
...
The fact that only one object of a class is used does not removes the benefits of using OO. In fact in many OO design there are only one instance of some class. The so called the gang of 4 (Gamma and all) have even defined a specific pattern called the "singleton" which is one of the most widely used pattern in OO design.

If interested in design pattern I recommend the bible: Design Patterns Gamma/Helm/Johnson/Vlissides (with preface from one of my guru Grady Booch) - for object design
as well as the more recent "Pattern Oriented Software Architecture" Buschmann/Meunier/Rohnert/Sommerlad/Stal. I recommend vol 1 (vol 2 is more specific to concurrent objects) - for architecture design

If you are concern with performance the old book (1992) C++ and C efficiency still provides valuable advice on how to improve program speed.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Thu Dec 29, 2011 8:03 pm

Here one of the reference (probably the best) if you want to code OO in C :
Object-Oriented Programming With ANSI-C http://www.planetpdf.com/codecuts/pdfs/ooc.pdf or http://www.cs.rit.edu/~ats/books/ooc.pdf

For code example goto http://lawker.googlecode.com/svn/fridge/lib/bash/ooc/
or directly to Schreiner, Axel-Tobias site at https://ritdml.rit.edu/handle/1850/8544

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Steem technical questions/problems

Postby Dio » Thu Dec 29, 2011 11:46 pm

In my opinion, using OO for emulation is overkill, classes are not really used several times in several objects (you have 1 MFP, 1 shifter, 1 FDC, ... (OK, there're 2 ACIA :) ).

OO is not just about reusability. In my day job I work within monthly-release, large C++ codebases. OO's chief advantage here is modularity - inheritance is not heavily used. Each component is a black box; the average programmer doesn't need to understand the internals of very many of the black boxes, only the interfaces that it exposes to the world. Each class is its own program, effectively. This approach, well guided by a few experienced system architects (one of which has, for the last year or so, been me), is the best way I've seen to produce long-term maintainable code. I was dubious about this benefit for a while, but compared to the large C codebases I've seen, even the ones which had started to evolve some kind of similar structure internally to try to control complexity, it's a total revelation. It creates code which is not only doing the job but still considered on a par with a scratch rewrite five, even ten years from inception on a monthly release cycle. It really works.

In addition, I think you haven't decomposed the problem well enough if you can't see the reusability in emulation. Each of the MFP, shifter, ACIA etc. has key things in common: connections to address and data buses, signal wires that go in and out to other parts of the system. Those are absolutely best described using two interfaces - a bus interface and a generic wiring interface - which are then manipulated by the emulator to connect to logical buses and other devices. In my opinion the best way to do that is with a generic abstract Device class and that's how Emu does it. Of course, I'm looking at a multisystem emulator, so I do get a fair bit of reusability between the different emulators.

npomarede wrote:As an example, MAME is written in C, and over the year it has evolved in a rather open model where it's quite easy to "plug" different cpu, audio chip, fdc, ... together to emulate a specific arcade board.

My main reason for doing Emu was the sheer ugliness and unfriendliness of MAME - originally, I did look at working within MESS for my own work, but found it too ugly for my purposes. In a multisystem emulator you have to define interfaces (which MAME does) and those are almost always more easily and cleanly done in C++ than in C (see my comment above; in my experience, complex C projects have a tendency to evolve some sort of OO structure internally, and if that's going to be the case, I would say it's better formalised in C++).

I think the goal of an emulator is to reach maximum accuracy with the best performance possible, rewritting Steem in C++ to reach this goal could be a necessary step if the people who want to improve Steem are more efficient with C++, but changing structures, operators, ... now from C to C++ just for the fun of rewriting it and in the hope others will continue later to work on Steem doesn't seem obvious to me (this is different from what Dio did, where he wrote Emu in C++ from the start).

I have a lot of sympathy for this view. But that said, a codebase needs to be maintainable going forward if it is to be extended further, and complex C projects that use globals out the wazoo generally, well, aren't.

Hippy Dave
Atari Super Hero
Atari Super Hero
Posts: 515
Joined: Sat Jan 10, 2009 5:40 am

Re: Steem technical questions/problems

Postby Hippy Dave » Fri Dec 30, 2011 2:26 am

projects have a tendency to evolve

C++ greatly assists in code thrashing. If a program evolved with 'if' and 'goto' instead of 'oo', any lack of design would be noticed sooner rather than later. C is good because it punishes you for lack of design, with a necessary code rewrite (sooner rather than later).

!cube
Atari maniac
Atari maniac
Posts: 80
Joined: Thu Jun 14, 2007 6:37 am
Location: Vantaa, Finland
Contact:

Re: Steem technical questions/problems

Postby !cube » Fri Dec 30, 2011 9:12 am

Don't want to quote the whole message from Nicolas so I'll just give my viewpoints on a few of the comments.

npomarede wrote:... but in the case of hardware emulation, I don't see the benefit of C++ (the GUI case is different, many toolkit were made from the ground up to be easier to use in C++ ). Of course, everyone is free to choose the language he prefers the most and where he's the most efficient, but performance-wise, I don't think C++ has some "nice features" over C in that case. C++ has nice features for readibility, reusability, but optimisation-wise I don't see why it would give better asm code than some well written C code.


Your last sentence kind of summarized just why one would want to make an emulator in C++. It aids greatly in readability and structural design. You can probably understand my point towards your argument on optimization if I ask you: "If you wanted an emulator that is optimized to the max, wouldn't you do it in asm instead of C?" I can hardly think you would, as it certainly wouldn't be as maintainable or readable as your C code. Further more, today's compilers will usually do a better job at optimizing your C code than what you would achieve if you wrote asm by hand. The same applies to the question of C vs. C++, maybe not as profoundly but still. The point is, C++ won't give better asm code than well written C, but it doesn't give worse code either, unless you're doing things like virtualization. If you implement the same thing in C and in C++, with regards to performance, the results are equal.

npomarede wrote:In my opinion, using OO for emulation is overkill, classes are not really used several times in several objects (you have 1 MFP, 1 shifter, 1 FDC, ... (OK, there're 2 ACIA :) ).


IMHO, OOP is only overkill if you're doing an application with the complexity of a "Hello World". In an emulator, you might not have multiple instances of a single class, but then again, in a fairly large number of cases, you don't. The whole point of using OOP in an emulator is to encapsulate the funtionality of a hardware block inside a single class, connected to other blocks via interfaces, because that's how the hardware was designed in the first place. The number of instances has no bearing on the matter.

So far, we, as in where I work, have done most of our hardware emulation models in C++, with a single exception of using C++ mixed with SystemC. An this has been for the simple reasons of readability, maintainability, debuggability, and ease of testing. We can give a task of implementing a specific hardware block to a single programmer, as the interfaces in an out of the block have been well defined. The person only needs to concentrate on his own implementation without having to fiddle around the whole codebase all the time. On testing, each programmer can do unit testing on their own blocks very easily. Regressions are much easier to find as they are specific to individual hardware blocks instead of being spread along the codebase. As an example, one of my colleagues implemented a hardware block without even submitting it to the main codebase. Only after he had tested it to be fully functional using unit testing, it was added to the codebase of the emulator.

As a footnote, I'd like to say that, there's nothing wrong with implementing an emulator in C, but, in my opinion, C++ gives you the means to implement it in a way that is far more practical. I don't have an issue with using C, on the contrary, I mostly implement my helper applications without OOP entirely. But, those applications are very specific, and do only very simple things. They are nowhere near the scale of a hardware emulator.
Last edited by !cube on Fri Dec 30, 2011 11:06 am, edited 5 times in total.
Kludge power since 1976.

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Steem technical questions/problems

Postby Dio » Fri Dec 30, 2011 9:49 am

Yeah, all good points.

I reckon the need for something like OO (fundamentally 'some sort of architecture) comes in once the project crosses some invisible line between about 1k and 10k lines. Or, another rule of thumb; if the project's large enough to need breaking into separate files, you've already started to modularise it, so it's probably large enough to benefit from breaking into modules and interfaces. OO is the most obvious way of achieving that at the moment.

User avatar
npomarede
Atari God
Atari God
Posts: 1241
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Steem technical questions/problems

Postby npomarede » Fri Dec 30, 2011 11:10 am

Well, I don't want to start a never ending debate, but as sure as badly written C can be horrible to maintain, badly written C++ can be even worse.
The problem is not on the need or not to define components as object/structure with well defined interface to the other components. I of course agree with this, this is the base of a good emulator where each component can be abstracted.
But once again, I don't see anything for an emulator (even one that mixes different components to emulate different computer/console) that benefits from C++ in readability : class -> use a structure, method -> use a function pointer in your structure and then you can write in C such things as "Shifter.ChangeColor ( 0, 0x777 )", C++ optimisations ? Once you don't use template/inheritance and few specific features of C++, I don't see what optimisations the C++ compiler could do that wouldn't apply to C to output asm.

I understand some people prefer working with C++ and I respect their choice, but in the end, I don't see any proof that an emulator written in C++ will work better than the C equivalent or will be more maintainable (once the correct structures are defined in C, it's not much harder to maintain/evolve them). I don't think either than C++ is required when project reach a certain number of lines. What is required is design, abstraction, well defined interfaces, good knowledge of the component to emulate : this is a mandatory work that doesn't even need to refer to a specific coding language ; once you've done this, the implementation in C or C++ would be in my opinion as good.

There're tons of examples / counter examples in open source of C and C++ projects that are both readable/maintainable or not, and in the end, this doesn't depend on the language : it depends on the skill of the coders, the organization of the project, the way people interact with each other (there's no question that a team of 10 talented C coders can produce much better code (in maintainability and performance) than a team of 50 average C++ coders, there's no "instant magic" in the choice of an OO language).

As for readibilty, I didn't say it was better in C++, I said it was a matter of taste, once again, you can't do general statement, it's really a case by case judgement (badly written code will me unreadable, whatever language you use).

I didn't claim C++ should not be used even if it gives similar result to C, I said that changing the language of an already written project such as Steem seemed odd to me and not necessarily the key to fixing everything. Steem code is certainly very badly organized (authors acknowledge this), with includes all around, need to recompile every files all the time, maybe too much global variables, ... This can be first fixed as C, without involving C++, in a progressive way ; else I'm afraid jumping directly to C++ will cause lots of regressions and unexpected results (due to some rather frequent "casts" between variable types in Steem for example).
That Dio wrote Emu from the start using C++ seems perfectly OK to me, why not using C++ ; but thinking that switching to C++ a badly organized C project will make it works better is wrong ; it's not changing the language that will improve the project, it's the time you will spent to re-think the whole design and the data structure/communication, and this work can then be applied to any language, OO or not.

Once again, I don't want to speak of C vs C++ in a general way, I just want to look at the case of emulators and more specifically to the case of Steem.

I don't want to advertise for Hatari in the Steem forum, but in a general emulator discussion, I really think that Hatari is a better example of C modularity/maintanability. Some people were able to contribute some code to Hatari (blitter, dsp, ...) without even having to understand the inner working of Hatari ; they changed some already defined general structures for the related component, added some code in only *one* specific C file, and in the end it worked (of course nothing is perfect, I don't claim Hatari to be completly abstracted and modularized as it should, but in the end, I think we will reach that goal and that the components of Hatari can be easily used in other projects to emulate a WD1772, or YM2149, ...)

PS : as for writting the emulator in asm directly, well yes, when I was a student, that what I did, I rewrote a lot of C code using asm directly on Atari/Amiga (packers, OS functions for faster drawing/text on screen, even my own UI toolkit with windows, drop down menu, themes, ... in complete asm without one single OS call), and honestly, I don't think the asm code was unreadable/unmainatable. Once again, it's more a matter of design/structures, than of language (asm will always look more "cryptic" than C/C++ when you're not used to it). Of course, that were different times, computers were much less powerful than today, you couldn't expect any C/C++ compiler to give the same results as hand optimized asm. These were the fun times :-)

Nicolas

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Steem technical questions/problems

Postby Dio » Fri Dec 30, 2011 12:14 pm

npomarede wrote:Well, I don't want to start a never ending debate, but as sure as badly written C can be horrible to maintain, badly written C++ can be even worse.

Oh yeah, hence why I was trying to deter Dr.Coolzic from some of the more esoteric C++ that was suggested before :) .

then you can write in C such things as "Shifter.ChangeColor ( 0, 0x777 )"

You can. But unlike C++, the compiler can't optimise this in the cases where ChangeColor isn't virtual.

C++ optimisations ? Once you don't use template/inheritance and few specific features of C++, I don't see what optimisations the C++ compiler could do that wouldn't apply to C to output asm.

I don't think anyone is arguing C++ produces more optimal code. It is easier to produce better organised source code in it though. And, sure, it is also easier to produce much worse organised source code too :D. C++ is a much more powerful tool, but you can do a lot more damage with a plasma cutter than a hacksaw...

I don't see any proof that an emulator written in C++ will work better than the C equivalent or will be more maintainable (once the correct structures are defined in C, it's not much harder to maintain/evolve them).

Proof? Programming is an art as much as a science ;) . But surely you offer some 'proof' yourself by arguing the C version isn't much harder to maintain; I would argue that it is harder, and therefore less maintainable :) .

I don't think either than C++ is required when project reach a certain number of lines. What is required is design, abstraction, well defined interfaces, good knowledge of the component to emulate : this is a mandatory work that doesn't even need to refer to a specific coding language ; once you've done this, the implementation in C or C++ would be in my opinion as good.

Which is what I said :D .

I'm afraid jumping directly to C++ will cause lots of regressions and unexpected results (due to some rather frequent "casts" between variable types in Steem for example).

Yeah, I couldn't agree more about this, and raised it before with my questions about source control.

PS : as for writting the emulator in asm directly, well yes, when I was a student, that what I did, I rewrote a lot of C code using asm directly on Atari/Amiga (packers, OS functions for faster drawing/text on screen, even my own UI toolkit with windows, drop down menu, themes, ... in complete asm without one single OS call), and honestly, I don't think the asm code was unreadable/unmainatable. Once again, it's more a matter of design/structures, than of language (asm will always look more "cryptic" than C/C++ when you're not used to it). Of course, that were different times, computers were much less powerful than today, you couldn't expect any C/C++ compiler to give the same results as hand optimized asm. These were the fun times :-)

Having done several 20k-plus lines of asm projects back in my ST / Falcon days, and (being the division's resident asm guru) still doing the odd hefty function in it now I for one am certain that asm is infinitely less maintainable than C / C++, no matter how much you break it up or macro-ise it.

For anything that doesn't benefit from vectorisation, the gains are close to nil anyway on any OOE architecture, although on in-order CPUs you can still see quite a big gain; x86/x64 compilers have got used to the CPU doing a lot of the hard work. It would be interesting to see if a compiler targetted at a universally in-order architecture like ARM was better in this regard, but gcc appears to generate worse code than MSVC as far as I've been able to see...

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Fri Dec 30, 2011 3:38 pm

speech is silver, but silence is golden :angel:

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Steem technical questions/problems

Postby Steven Seagal » Mon Jan 02, 2012 7:49 pm

About C/C++, I'm neutral.

For C++:
- When you start using prefixes in C like Shifter_change_sync, Shifter_change_res,etc., you wonder if it isn't more elegant to use C++ Shifter.ChangeSync, Shifter.ChangeRes, etc. Classes are a nice feature, an extension of structures. Using pointers instead is rather ugly, and an admission you need C++.
- The 'indirection' penalty of C++ is a false problem. I think video rendering is what takes cycles in emulation, and Direct X / SDL / GDI etc. platform will make the difference. I know what makes Steem crawl.
- RAII (Resource Acquisition Is Initialisation)
- Maybe even exceptions.

For C:
- When you're trying things my way, you're glad all global variables are readily available instead of 'encapsulated'.
- There are lots of technical issues and complications with C++, like pointers to member functions; what is or not inlined? On one side they tell you don't use evil macros, use inline functions, when you do it, it's not inlined for this or that reason, and compilers have each its behaviour, screw that!
- C compilers are quicker and simpler, with fewer cross-platform issues. In C++, there's not even a linking standard.
- Templates, I prefer to say nothing about them.
- Generally, I don't like the direction C++ has taken since 1998, that's why I stick with VC6.

As an amateur, I use the classes features of C++, but I wouldn't dare recommend that any group switch from C to C++.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Steem technical questions/problems

Postby Dio » Mon Jan 02, 2012 10:03 pm

Crikey. If there's one thing you should do tomorrow it's to take your VC6 disks and burn them, if you're planning to compile C++ at least. Apart from the fact that it's ridiculously anti-standard in places, in my experience the compiler is rammed full of bugs. I generally found VC hard work before VC2005. 2008 and 2010 are worth going to as well because the IDE is so much better.

The 'indirection' penalty of C++ is a false problem. I think video rendering is what takes cycles in emulation, and Direct X / SDL / GDI etc. platform will make the difference. I know what makes Steem crawl.

Modern CPUs hate chains of pointers if the working set of the program is larger than the cache - although it's not always trivial to see if this is a real effect or just a measurement artifact on CodeAnalyst / VTune because they cause an instruction to retire later than one would otherwise expect but the CPU is still achieving something in the meantime. Certainly, with C++ this can be worse, but a C program is likely to suffer the same issues.

The actual rendering process of the video (DirectX and the like) isn't a huge cost. It's almost always the CPUs that hurt.

Emu breaks down like this while running the ST (sat at the desktop):
Sleep: 87%
Scheduler (basically, event / timing management): 1.3%
CPU: 6.8%
Sound: 0.4%
ST Video conversion to RGB: 1.3% (one of the few bits of asm, just a couple of lines of SSE code)
DirectX Lock overheads: 0.2%
RGB upload to offscreen surface: 1.2%
Stretch blit to backbuffer: 0.2%
Present: 0.5%
(So total video cost: 3.4%)
Windows overheads: 1.5%
Input: < 0.1%.

Now, the CPU management for the timing to do the video accurately, flush it all at the right places on register writes and the like, is not quite so trivial. I reckon that adds between 25% and 50% to the cost of the CPU and scheduler - although with a pure flushable model the cost could be pushed down to 0, that's a lot harder to write than a timed model.

To be fair, Emu's flexible scheduling is not totally optimal for a single-system emulator, and you can probably do a faster 68000 core than the one I have, (which is built out of inlined template functions :) ) but I doubt a factor of 2 is available while still accurately emulating prefetch and the like, so I still think the CPU will cost more than the video transfer process does for an 8MHz 68000. And certainly it's more balanced in the Spectrum, where the Z80/scheduler costs 3% and the video 2.5%, because the CPU is so much less taxing and the screen is smaller.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2188
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Steem technical questions/problems

Postby DrCoolZic » Thu Jan 12, 2012 5:03 pm

!cube wrote:So far, we, as in where I work, have done most of our hardware emulation models in C++, with a single exception of using C++ mixed with SystemC.

Little bit out of subject but I received today notification from SystemC:
ANNOUNCEMENT: SystemC v2.3 public review now available TIME PERIOD: Now through March 3, 2012
Documents can be found at http://www.accellera.org/downloads/drafts_review/
with pretty exciting expanded dynamic process capabilities ... Thought you might be interested ;)


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 1 guest