gxemul-devel

[GXemul-devel] gxemul++?

[Nils W. <ni...@gn...>]

Hello!

gxemul is a wonderful project. However, I heard that it is being rewritten
in C++ instead of C. I wonder what will be done differently and what major
new features or approaches to certain problems can we expect from the
rewrite?

Thanks,
Nils

Re: [GXemul-devel] gxemul++?

[Anders G. <ga...@gm...>]

On Mon, 2008-03-10 at 20:28 +0100, Nils Weller wrote:
> Hello!

Hi Nils,

> gxemul is a wonderful project. However, I heard that it is being rewritten
> in C++ instead of C. I wonder what will be done differently and what major
> new features or approaches to certain problems can we expect from the
> rewrite?

Thanks. Well, the main purpose of rewriting in C++ is for me to get more
used to using C++ in a realistically-sized project (apart from stuff at
work, which is completely unrelated to Emulation). The other main reason
for the rewrite is that GXemul has become too hard to extend, without
breaking older stuff. The dyntrans core, for example, was extremely hard
to maintain. I simply needed a fresh start. (So there are no specific
technical reasons for choosing C++ over C.)

Regarding new features, well, the older version did not really have a
clean concept of what an "emulation setup" was. It was not possible to
save/load full state of an emulation, nor was it possible to fully
describe an emulation using only a configuration file (it was often
necessary to write setup code for individual machines directly in C).
Every new feature or device just felt like yet another hack.

If everything goes as planned, 0.5.0 will have a native GUI. (Optional,
of course.)  And appart from forward-porting the older supported
emulated archs, I'd like to get time to work on M88K, Alpha, SPARC, and
amd64/i386 emulation too.

Hopefully I will also have time to work more on translation to native
code again (remember that 0.4.x only did dynamic translation to IR, not
to native code).

Time will tell what kind of features I will have time to implement.
Don't expect any release soon. :)


Anders

Re: [GXemul-devel] gxemul++?

[Anders G. <ga...@gm...>]

Hi.

I'm answering myself :) as a kind of status update for anyone interested
in reading about the development of what will hopyfully become GXemul
0.6.0.

> On Mon, 2008-03-10 at 20:28 +0100, Nils Weller wrote:
> > Hello!
> 
> Hi Nils,
> 
> > gxemul is a wonderful project. However, I heard that it is being
> > rewritten in C++ instead of C. I wonder what will be done
> > differently and what major new features or approaches to certain
> > problems can we expect from the rewrite?
>
> Thanks. Well, the main purpose of rewriting in C++ is for me to get 
> more used to using C++ in a realistically-sized project (apart from
> stuff at work, which is completely unrelated to Emulation). The other
> main reason for the rewrite is that GXemul has become too hard to
> extend, without breaking older stuff. The dyntrans core, for example,
> was extremely hard to maintain. I simply needed a fresh start. (So
> there are no specific technical reasons for choosing C++ over C.)

During my summer vacation, I've been trying to get up to speed again on
the C++ rewrite.

The C++ features that I have noticed that I use/enjoy most are:

o) Automatic destructors. In the old C parts of GXemul, all allocations
   and deallocations were explicit. In C++, much of the deallocation
   work (and some of the allocation work) can be taken care of by the
   language. This makes the code shorter and less error prone. There are
   no 'malloc' nor 'free' calls, nor even explicit 'delete' calls, in
   the new code.

o) C++ strings, instead of raw C char arrays.

o) STL containers.

o) Inheritance, instead of sub struct hacks which were necessary in C.

o) Virtual function overrides, instead of explicit function pointer 
   calls, which were necessary in C.

C++ features that I have _not_ used much are:

o) Exceptions. There is a kind of catch-all exception handler which 
   aborts the emulator, but exceptions are not used internally yet for
   other kinds of error handling.

o) Templates. Apart from the obvious uses (reference counting pointers,
   STL usage), I have only used templates in very few places.
   
   One could imagine that the dyntrans core in GXemul 0.4.x (the
   "macro/include hell") could be converted straight off to "template
   hell". Maybe that could have been one possibility. But that has not
   been done.

> Regarding new features, well, the older version did not really have a
> clean concept of what an "emulation setup" was. It was not possible to
> save/load full state of an emulation, nor was it possible to fully
> describe an emulation using only a configuration file (it was often
> necessary to write setup code for individual machines directly in C).

Save/load of full emulation state is implemented in the new framework.

Another consequence of dealing with state in a more reasonable way is
that single-stepping now prints _all_ state changes (except changes to
RAM contents, at the moment). For example, imagine a read from a
zero-on-read status register in some device:

  machine0.mainbus0.cpu0: 0x12345678  ab cd 01 00  ld r12,[r13+0x100]
  => machine0.mainbus0.isabus0.somedevice0.status: 0x0014 -> 0x0000
  => machine0.mainbus0.cpu0.r12: 0x2828 -> 0x0014

(Zero-on-read registers such as the example above are common in real
world devices, such as interrupt controllers.)

In the old framework, it was up to each individual device to explicitly
output debug data about what it does. In the new framework, components
_may_ output something, but even if they don't, the change in state
will be possible to show to the user.

Two things that are worth mentioning that are done differently in the
new framework are:

o) CPUs per machine. In the old framework, a machine had 1 or more CPUs 
   of a particular architecture. It was not really possible to have
   different CPUs of different architecture in the same machine. In the 
   new framework, a CPU is on a more equal level with other components,
   and it should be possible to mix CPU architectures within the same
   machine. (A real-world example of where multiple architectures are
   used is the Dreamcast, which has an SH4 main CPU, and an ARM cpu for
   sound processing.)

   (In fact, even the "machine" concept is now a big vague... a machine
   in the new framework is a component with some sub-components.)

o) RAM. The old framework treated RAM as a kind of mainbus, which was
   always present (one per machine), mapped at offset 0. Kind of. Except
   for SGI machines, where there was an offset. And except for the RAM
   _device_, which was not like the main RAM. Very ugly. And there was
   special treatment of the RAM device, in order to make it work with
   the dyntrans system's view of memory. In the new framework, there is
   (usually) a mainbus in each machine, to which things are connected,
   and RAM is one such connected component. No more special cases.

http://gxemul.svn.sourceforge.net/viewvc/gxemul/gxemul/trunk/doc/intro.html#newvsold
has another short description of the new framework.

> Every new feature or device just felt like yet another hack.

It's a tricky balance to choose between "release early" and "take the
time to do something right". Previous versions of GXemul were often very
quickly rushed out the door, so to speak. Grepping for TODO in GXemul
0.4.7.2 shows over 1400 TODO lines in the source code (_plus_ the TODO
file itself). Hopefully, future releases will be less rushed, and some
of those TODOs can be fixed while porting stuff from the old to the new
framework.

> If everything goes as planned, 0.5.0 will have a native GUI.
> (Optional, of course.)

0.5.0 was planned to be a clean rewrite from scratch with _no_ legacy
code in it at all. This has been scrapped. The GUI has been scrapped.
The 0.5.0 development branch also had preliminary Undo/Redo support.
This has been scrapped as well.

Instead, 0.6.0 will be the new framework _and_ the legacy code in _one_
tree. To the end user, the old emulation modes from 0.4.x are still
there. When the user follows steps in the documentation about legacy
modes, they should still be valid. The old and new framework are very
different, however, so code is not reused between the old and new
framework.

> And appart from forward-porting the older supported
> emulated archs, I'd like to get time to work on M88K, Alpha, SPARC,
> and amd64/i386 emulation too.

Motorola 88100 emulation has already been implemented in the old
framework, in releases 0.4.7.x. As for the other modes, they might get
implemented in the future some time, if time permits.

No exact date is set yet for the release of 0.6.0. It will be released
when _something_ is emulated in a stable and meaningful manner with the
new framework. I'm primarily focusing on the testm88k machine, to
minimize the impact on the other emulation modes. Many major parts need
to be written before the release. Maybe a release will happen before
xmas then ;)

I don't imagine that 0.6.0 will be bug free (especially when it comes to
documentation vs how things really work), but it will be a reasonable
starting point.

If you want to try to build the latest development tree, simply type

  svn co https://gxemul.svn.sourceforge.net/svnroot/gxemul/gxemul/trunk
gxemul
  cd gxemul
  ./configure && make test

Feel free to report any problems. :)


Anders

Re: [GXemul-devel] gxemul++?

[Anders G. <ga...@gm...>]

..
> No exact date is set yet for the release of 0.6.0. It will be released
> when _something_ is emulated in a stable and meaningful manner with the
> new framework. I'm primarily focusing on the testm88k machine, to
> minimize the impact on the other emulation modes. Many major parts need
> to be written before the release. Maybe a release will happen before
> xmas then ;)

After more than two years of sporadic work on the rewrite, something
finally runs: the rectangle drawing demo for testm88k. :)

But just barely. There are no lookup tables for fast loads/stores, no
fast pc-to-pointer lookups, no interrupt/trap/exception handling,
no breakpoint support, no general expression parsing, no disk or
ethernet support, no MMU/virtual memory translation, and no I/O (neither
serial controllers nor graphical output handlers).

And there are many bugs.

Still, small steps in the right direction.

$ ./gxemul -Ve testm88k test/FileLoader_A.OUT_M88K
GXemul (unknown version)      Copyright (C) 2003-2010  Anders Gavare

  mainbus0
  |-- cpu0  (88100, 50 MHz)
  |-- ram0  (32 MB at offset 0)
  |-- fb_videoram0  (15 MB at offset 0x12000000)
  \-- rom0  (4 MB at offset 0xff800000)

cpu0: test/FileLoader_A.OUT_M88K loaded
      a.out: entry point 0x000012b8
      text + data = 4096 + 4096 bytes
      symbols: 1260 bytes at 0x2000
      strings: 1070 bytes at 0x24ec
      13 symbols read

GXemul> cpu0.showFunctionTraceCall = true 
=> cpu0.showFunctionTraceCall: false -> true
GXemul> continue
[ cpu0: _change_resolution(800,600,0,0,0,0,0,0,...) ]
[ cpu0:   _fbctrl_set_x1(800,600,0,0,0,0,0,0,...) ]
[ cpu0:     _fbctrl_write_port(1,600,0,0,0,0,0,0,...) ]
[ cpu0:     _fbctrl_write_data(800,600,0,0,0,0,0,0x12f00000,...) ]
[ cpu0:   _fbctrl_set_y1(600,600,0,0,0,0,0,0x12f00010,...) ]
[ cpu0:     _fbctrl_write_port(2,600,0,0,0,0,0,0x12f00010,...) ]
[ cpu0:     _fbctrl_write_data(600,600,0,0,0,0,0,0x12f00000,...) ]
[ cpu0:   _fbctrl_command(1,600,0,0,0,0,0,0x12f00010,...) ]
[ cpu0:     _fbctrl_write_port(0,600,0,0,0,0,0,0x12f00010,...) ]
[ cpu0:     _fbctrl_write_data(1,600,0,0,0,0,0,0x12f00000,...) ]
[ cpu0: _my_random(1,600,0,0,0,0,0,0x12f00010,...) ]
[ cpu0: _my_random(0x8eb1badd,258,0,0,0,0,0x96219136,0xe3abd777,...) ]
[ cpu0: _my_random(0x6c3eea31,258,0,0,0,0,0x96219136,0x9a0bfc0b,...) ]
[ cpu0: _my_random(0x159ec14d,258,0,0,0,0,0x96219136,0xd96944e7,...) ]
[ cpu0: _my_random(0x56fc79a1,258,0,0,0,0,0x96219136,0x30a2827b,...) ]
[ cpu0:
_draw_rectangle(381,513,109,185,0xbf37bf3d,0,0x96219136,0x1c9221d7,...) ]
[ cpu0:
_my_random(381,513,109,185,0xbf37bf3d,0,0x96219136,0x1c9221d7,...) ]
[ cpu0:
_my_random(0x93071c91,201,6d,b9,0xbf37bf3d,0,0x96219136,0x2d57546b,...) ]
[ cpu0:
_my_random(0xa2c2692d,201,6d,b9,0xbf37bf3d,0,0x96219136,0x38c76ac7,...) ]
[ cpu0:
_my_random(0xb7525781,201,6d,b9,0xbf37bf3d,0,0x96219136,0x96563e5b,...) ]
[ cpu0:
_my_random(0x19c3031d,201,6d,b9,0xbf37bf3d,0,0x96219136,0x1fd1a3b7,...) ]
[ cpu0:
_draw_rectangle(17,101,481,117,0x90449ef1,0,0x96219136,0xfe6cfccb,...) ]
[ cpu0:
_my_memset(0x1203b313,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0xfe6cfccb,...) ]
[ cpu0:
_my_memset(0x1203bc73,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x1203c5d3,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x1203cf33,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x1203d893,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x1203e1f3,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x1203eb53,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
^C
[ cpu0:
_my_memset(0x1203f4b3,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x1203fe13,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x12040773,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x120410d3,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x12041a33,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x12042393,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x12042cf3,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ cpu0:
_my_memset(0x12043653,0x90449ef1,0x573,75,0x90449ef1,0,0x96219136,0,...) ]
[ 100000 steps (6450 steps/second) ]
GXemul> fb_videoram0.dump 0x3b300 
TODO: parse address expression
(for now, only hex immediate values are supported!)
0003b300  00000000 00000000 00000000 00000000  ................
0003b310  000000f1 f1f1f1f1 f1f1f1f1 f1f1f1f1  ................
0003b320  f1f1f1f1 f1f1f1f1 f1f1f1f1 f1f1f1f1  ................
0003b330  f1f1f1f1 f1f1f1f1 f1f1f1f1 f1f1f1f1  ................


Anders