[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C# or C++ for Emulator?
- Subject: Re: C# or C++ for Emulator?
- From: Eric <englere_geo@yahoo.com>
- Date: Mon, 13 Aug 2007 14:59:34 -0700
- Complaints-to: groups-abuse@google.com
- In-reply-to: <46bf4921$0$4856$4c368faf@roadrunner.com>
- Injection-info: l70g2000hse.googlegroups.com; posting-host=216.206.90.2; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0
- Newsgroups: comp.sys.apple2
- Organization: http://groups.google.com
- References: <46bf4921$0$4856$4c368faf@roadrunner.com>
- User-agent: G2/1.0
- Xref: g2news2.google.com comp.sys.apple2:2329
On Aug 12, 1:54 pm, "Bryan Parkoff" <nos...@nospam.com> wrote:
> I can't tell which C# or C++ is better programming language. C# is
> better than C++ for readable code, but C++ is better than C# for tuning
> optimization.
Since C# is JIT compiled, you pay a penalty up front when a class is
entered but after that it's running as optimized native code. Since it
JITs on the target computer and not on the build computer it can even
optimize things in a target-specific manner. Most C++ compiles are
done to the lowest common denominator so they can't take advantage of
extra CPU features a given target may have. To be fair, I don't think
they fully utilize this yet but it's an interesting idea.
You can find some emulator source on the web for both languages. C++
has a lot of projects but I only saw one for C# and it wasn't
completed.
> I prefer fast code without error trapping.
When you say "error trapping", do you mean "exception handling"? It
does not significantly slow down C# unless an exception is actually
thrown. I guess it's the same for C++ but I am not an expert on that.
Are you confusing exception handling with strong typing? Strong typing
can slow down C# more than C++ since the code is type checked at
runtime and you can't turn that off. There are a lot of checks done at
runtime with C# programs and this is what slows them down. Safety is
the buzzword, since it's based on Java.
> I wonder that C# is not portable to other machines?
What makes you say that? It is an ISO standard and it has been ported
to many machines through the mono project. Of course, it needs a
fairly strong 32 bit processor in most cases, so an 8 bit port would
not be efficient. But it is possible. Nothing precludes it from
working, assuming you take liberties with the CLR in a similar way
than NanoVM redefines the JVM for small devices. But I don't think
you're asking about running C# compiled code directly on the Apple so
this is not pertinent.
> If you choose dynamic recompilation, ROM image and
> DSK image must be converted from 6502 code machine into 80x86 code machine
> once before ROM image and DSK image with 80x86 code machine can be run.
This is a non-starter! It would be incredibly complex and you'd
probably never finish the project.
Although I love C#, I'm not trying to steer you that way. I'd probably
prefer a flat C emulator if I were writing it. I'd want to avoid
garbage collection and runtime type checking. The OOP in C++ doesn't
have too much overhead by itself, but the standard C++ libraries can
bring in a lot of runtime baggage. Emulators have to lean and mean.
I'd also want to leverage third party developed emulator support
routines, assuming this is going to be an open source project. If this
will be closed source you have to avoid taking other people's code
without a good understanding of the licensing terms.
Eric