gxemul-devel — Mailing list for discussions regarding GXemul's development

Re: [GXemul-devel] [GXemul-users] Gxemul

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

Hi Vincent,

Tis 2010-05-11 klockan 01:20 -0400 skrev Vincent Mirian:
> Hi all,
> 
> I have a few questions... :-)
> 
> I would like to create execution traces of a mips processor from
> gxemul. I would like to run the simulation for a while (until a
> breakpoint let's say) and then save the _execution_ traces in a file.

I didn't quite understand which of the following two you want to do:

a) run for a while (tracing instructions), hit a breakpoint, exit
(saving the traced instruction)

or

b) run for a while without instruction trace, hit a breakpoint, turn on
instruction trace, and then continue (saving instruction trace from here
on).

Both should be possible by hacking the source code. A brutal one-off
approach could be to just hack in something in
DYNTRANS_RUN_INSTR_DEF(struct cpu *cpu) in cpu_dyntrans.cc, like

	if (single_step || cpu->machine->instruction_trace
	    || cpu->machine->register_dump) {
		/*
		 *  Single-step:
		 */
FILE *old = stdout;	// HACK!
stdout = fopen("trace-output.txt", "a");	// HACK!

		struct DYNTRANS_IC *ic = cpu->cd.DYNTRANS_ARCH.next_ic;

...

		/*  Execute just one instruction:  */
		I;

		n_instrs = 1;

fclose(stdout);	// HACK!
stdout = old;	// HACK!

	} else if (cpu->machine->statistics.enabled) {

to redirect stdout to a file during single step and instruction trace.
But it would probably be horribly slow.

>  Furthermore, I do not want to trace the cycle time that the processor
> is halted for memory requests.

That's easy. (Because GXemul currently does not simulate caches or
memory latencies. :-))


Anders

[GXemul-devel] Gxemul

[Vincent M. <vin...@ho...>]

Hi all,

I have a few questions... :-)

I would like to create execution traces of a mips processor from gxemul. I would like to run the simulation for a while (until a breakpoint let's say) and then save the _execution_ traces in a file. Furthermore, I do not want to trace the cycle time that the processor is halted for memory requests. Any tips/suggestions on how to proceed with this?

Also, does anyone know of a soft mips processor that contains atomic operations (mutex lock/unlock) in their architecture?

Thank you,
Vince

Eco-Tip: Save trees! Do you really need to print this email? ;-)
 		 	   		  
_________________________________________________________________
30 days of prizes to be won with Hotmail.  Enter Here.
http://go.microsoft.com/?linkid=9729709

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

Re: [GXemul-devel] patch about dev_ether.c (YanaKernel0 Prototype + uIP)

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

Mån 2010-01-25 klockan 21:30 +0900 skrev Yana:
..
> Because GXemul(testarm) terminated with "Aborted (core dumped)" or
> "Segmentation fault (core dumped)", I patched gxemul-0.4.7.2.tar.gz.
> 
> There seems to be a problem in dev_ether.c.
..
> +#else /* patch */
> +				if (net_ethernet_rx(cpu->machine->emul->net, d, &incoming_ptr,
> &incoming_len) != 0) {
> +#endif

Thanks. Patch applied as SVN revision 5637.


Anders

[GXemul-devel] patch about dev_ether.c (YanaKernel0 Prototype + uIP)

[Yana <op...@ya...>]

Hello,

I used GXemul with YanaKernel0 Prototype.
http://yana.jp/

Because GXemul(testarm) terminated with "Aborted (core dumped)" or
"Segmentation fault (core dumped)", I patched gxemul-0.4.7.2.tar.gz.

There seems to be a problem in dev_ether.c.

Thanks,

Yana


diff -ru _/gxemul/src/devices/dev_ether.c gxemul/src/devices/dev_ether.c
--- _/gxemul/src/devices/dev_ether.c	2009-06-22 01:03:48.000000000 +0900
+++ gxemul/src/devices/dev_ether.c	2010-01-11 00:00:00.000000000 +0900
@@ -146,9 +146,13 @@
 				fatal("[ ether: RECEIVE but no net? ]\n");
 			else {
 				d->status &= ~DEV_ETHER_STATUS_PACKET_RECEIVED;
+#if 0
 				net_ethernet_rx(cpu->machine->emul->net,
 				    d, &incoming_ptr, &incoming_len);
 				if (incoming_ptr != NULL) {
+#else /* patch */
+				if (net_ethernet_rx(cpu->machine->emul->net, d, &incoming_ptr,
&incoming_len) != 0) {
+#endif
 					d->status |=
 					    DEV_ETHER_STATUS_PACKET_RECEIVED;
 					if (incoming_len>DEV_ETHER_BUFFER_SIZE)

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] build fix for current SVN trunk

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

Tis 2009-01-13 klockan 13:51 +0100 skrev Markus Dahms:
> I need the following patch to build current GXemul trunk on Linux/i386
> with gcc 4.3.2 as -Werror is enabled.
..
> +/* for strdup() */
> +#include <string.h>

Thanks. Applied as revision 5388.


Anders

[GXemul-devel] build fix for current SVN trunk

[Markus D. <ma...@au...>]

Hi,

I need the following patch to build current GXemul trunk on Linux/i386
with gcc 4.3.2 as -Werror is enabled.

Besides, there seems to be a problem with the mailing list (configuration
error or problem on SF side): all confirmation requests an so on are sent
to ${USER}-owner@${DOMAIN}, if I hadn't configured a catch-all account I
would have missed these mails.

Greetings,

	Markus

--- a/src/main/GXemul.cc
+++ b/src/main/GXemul.cc
@@ -282,6 +282,8 @@
 #include <fstream>
 #include <iostream>
 
+/* for strdup() */
+#include <string.h>
 
 /*  main.c:  */
 extern "C" int old_main(int argc, char *argv[]);

Re: [GXemul-devel] GXemul 0.4 target PPC

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

Ons 2008-07-16 klockan 09:12 +0200 skrev claude vittoria:
> Hi,
> 
> I implement Float instructions in PPC target with softfloat.
> 
> I m looking for an advice.
> 
> Each float instruction, need to test if FPU is enable. Thus I
> need the reel PC to launch fpu exception.
> In ic->args, I can only give 3 parameters (Rd, Ra, Rb). I don't
> want to provide the word in args and to decode it in the
> instruction.
> 
> I try to use this code.
> 
> int low_pc = ((size_t)cpu->cd.DYNTRANS_ARCH.next_ic - 
>        (size_t)cpu->cd.DYNTRANS_ARCH.cur_ic_page) 
>        sizeof(struct DYNTRANS_IC);   
>    cpu->pc &= ~((DYNTRANS_IC_ENTRIES_PER_PAGE-1) << 
>        DYNTRANS_INSTR_ALIGNMENT_SHIFT);  
>    cpu->pc += (low_pc << DYNTRANS_INSTR_ALIGNMENT_SHIFT);

There is already a macro for this, CHECK_FOR_FPU_EXCEPTION, in
cpu_ppc_instr.c. See e.g. the implementation of the fctiwz or fneg
instructions for example on how it is used.

..
> I get the pc+4 where is the instruction. It seems fine.
> 
> But I see your implementation of mtmsr and I don't understand why you
> don't use the code, above, when the instruction is executed. 
> I don't find argument...

mtmsr is not a good example to copy, because it contains a special hack.
fneg is better.

> Other question
> If I want to give a fourth argument in ic (arch ## _instr_call), I
> need to reduce the number of translated instructions ? I don't test
> this modification because I don't see all impacts...

If you really need to expand the number of arguments, then edit
PPC_N_IC_ARGS in src/include/cpu_ppc.h.


Anders

[GXemul-devel] GXemul 0.4 target PPC

[claude v. <vit...@wa...>]

Hi,

I implement Float instructions in PPC target with softfloat.

I m looking for an advice.

Each float instruction, need to test if FPU is enable. Thus I need the reel PC to launch fpu exception.
In ic->args, I can only give 3 parameters (Rd, Ra, Rb). I don't want to provide the word in args and to decode it in the instruction.

I try to use this code.

int low_pc = ((size_t)cpu->cd.DYNTRANS_ARCH.next_ic - 
       (size_t)cpu->cd.DYNTRANS_ARCH.cur_ic_page) 
       sizeof(struct DYNTRANS_IC);   
   cpu->pc &= ~((DYNTRANS_IC_ENTRIES_PER_PAGE-1) << 
       DYNTRANS_INSTR_ALIGNMENT_SHIFT);  
   cpu->pc += (low_pc << DYNTRANS_INSTR_ALIGNMENT_SHIFT);

I get the pc+4 where is the instruction. It seems fine.

But I see your implementation of mtmsr and I don't understand why you don't use the code, above, when the instruction is executed. I don't find argument...

Other question
If I want to give a fourth argument in ic (arch ## _instr_call), I need to reduce the number of translated instructions ? I don't test this modification because I don't see all impacts...

Best regards,
Claude

Re: [GXemul-devel] GXemul ARM bkpt patch

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

Tis 2008-06-10 klockan 11:20 +0200 skrev Jiri Svoboda:
> Hello,

Hi Jiri. (I'm sending this reply to gxemul-devel as well, I hope that is
ok with you.)

> I am working on debugging support for the HelenOS operating system as
> a part of my master thesis. While working on this I ran into GXemul
> not supporting the BKPT instruction on ARM (BKPT is defined in ARM
> architecture v5 and above). I made a patch against GXemul 0.4.6.3
> adding support for this instruction. It would be cool if you could
> integrate it (or something equivalent).
...
> /*
>  * bkpt:  Breakpoint instruction.
>  */
> void arm_instr_bkpt(struct cpu *cpu, struct arm_instr_call *ic)
> {
>       /*  Synchronize the program counter first:  */
>       cpu->pc &= 0xfffff000;
>       cpu->pc += ic->arg[0];
>       arm_exception(cpu, ARM_EXCEPTION_DATA_ABT);
> }
... 
>
>               /* "bkpt" */
>               if ((iword & 0xfff000f0) == 0xe1200070) {
>                       ic->f = arm_instr_bkpt;
>                       ic->arg[0] = addr & 0xfff;
>                       break;
>               }

Thanks for your patch. I'm applying it, with some modifications.

The way ARM instructions are implemented in the cpu_arm_instr.c file is
with X() and Y() macros; if you look at e.g. the X(swi) macro call
(which indeed expands to arm_instr_swi(struct cpu *cpu, struct
arm_instr_call *ic)) you will see that it is followed by a Y(swi) as
well.

That is what enables the 4-bit condition code stuff.

Similarly with  ic->f = arm_instr_bkpt;  which does not take the
condition code into account. The cond_instr() macro is used instead.

So the end result is:


/*
 * bkpt:  Breakpoint instruction.
 */
X(bkpt)
{
        /*  Synchronize the program counter first:  */
        cpu->pc &= 0xfffff000;
        cpu->pc += ic->arg[0];
        arm_exception(cpu, ARM_EXCEPTION_PREF_ABT);
}
Y(bkpt)

and

/*  "bkpt", ARMv5 and above  */
if ((iword & 0x0ff000f0) == 0x01200070) {
        ic->arg[0] = addr & 0xfff;
        ic->f = cond_instr(bkpt);
        break;
}


Note: the ARM manual I have here says that the bkpt instruction should
behave as a "Prefetch Abort", not "Data Abort". Are you sure
that ARM_EXCEPTION_DATA_ABT is the right choice? I'm using
ARM_EXCEPTION_PREF_ABT for now (vector 0x000c).

(I also added disassembly support in cpu_arm.c.)

Hopefully I'll have time to make a 0.4.6.4 release soon; I did another
ARM fix a few days ago in the 0.4 branch, which would be good to
release.


Anders

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

[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

[Gxemul-devel] testing 123

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

Testing. 123. Etc.

Anders