| |
| |
| |
|
Page: 1 2
Comments:
<0> ah, okay
<0> you still use gcc to compile the micro-ops then
<1> No.
<0> okay
<1> That's the difference.
<0> and you have to write the code generation for each host arch?
<1> Currently qemu blindly glues together opaque lumps of gcc output. The new system knows how to generate host code for each op.
<1> Yes, you have to write the low-level code generion bits for each host.
<0> okay, that's all I was wondering
<1> However you only really have to provide templates for basic instructions, things like register allocation are shared between all hosts.
<0> doesn't sound too tough, then.
<1> Most the host specific bits are in the host-* directories.
<1> I can probably do a new host architecture in a couple of weeks.
<1> Thought the current structure means that debugging the host bits can be ..um.. entertaining.
<1> I was overly clever with the C preprocessor. Recursive #includes rock :-)
<0> btw, randolph chung has actually got the hppa host support I'd started on almost working.
<0> (although tbh, practically none of my code remains)
<2> do qemu's goals including emulating any and all cpus, or 32/64 bit cpus in particular?
<2> any plans to support microcontrollers?
<1> I've got emulation of an arm/Cortex based Luminary microcontroller I hope to submit soon.
<1> I'm not aware of anyone working on any 8/16 bit targets, but it's certainly doable.
<1> That's certainly possible.
<0> as it's a relatively simple cpu
<0> not quite sure about system emulation
<0> :)
<1> It's unclear whether there's much benefit using qemu for tiny little 8-bit cpus though.
<1> You generally don't need the performance.
<0> well, quite.
<1> If you can reuse some of the peripherals it might be useful.
<0> is there much harm?
<0> (I wouldn't expect the code to be merged)
<1> I've no objection in principle.
<0> slava: are you interested in anything in particular?
<2> no, i was just curious
<2> i'm only using qemu for arm emulation
<1> e.g. my Limunary microcontroller shares many of its peripherals with full-size arm boards.
<0> would amiga/st/m68k-mac emulation be okay in principle?
<3> are any of virtualbox ideals going to be implemented ie visualization parts
<1> ... where "full size" is a relative term and means cellphones :-)
<1> allix: Depends whether anyone bothers to implement it. kvm already uses qemu.
<0> way off in the future, I'm thinking about openrisc and mmix
<1> sdbrady: Yes. qemu already has a ColdFire target, which is basically a m68k with a few bits missin.
<1> Implementing ColdFire system emulation is on my list of things to do.
<0> I'll bear that in mind then. hope I eventually get round to it.
<1> The problem with 68k macs is the lack of hardware documentation.
<0> yeah, I've heard
<1> Most mac68k emulators work by hooking the macos firmware routines rather than emulating hardware.
<0> "I don't care if space-aliens ate my mouse"
<2> what is coldfire used for these days?
<0> an interesting read
<1> The mvme 68k based boards look fairly well documented, and can run linux. I'd probably start with one of those.
<0> pbrook: ewww. although, hey, that's kinda cool :)
<1> ColdFire is typically used for embedded control systems. Engine management, that kind of thing.
<1> The high-end chips can do FP, and run linus, so possibly things like printers.
<3> alphas is a interesting platform
<3> i saw that its can be a host os
<4> mac os x is supported?
<1> Not really.
<1> It's illegal to run osx on anything other than Apple hardware.
<1> You can get osx x86 running inside qemu by hacking it the same way you do to make it run on any other pc.
<5> pbrook: i'm still investigating that issue i mentioned before. the point where it exits is a function call, it never makes it into the function. but what is quite strange is
<5> the fact that if i comment out that function call, it exits in some other place later in the program
<1> You know that gdb will step over fuction that it doesn't have debug info for?
<5> pbrook: i went the printf way
<1> Stack overflow maybe?
<5> i thought so, but why would that happen in only in qemu and not on the real target ?
<1> qemu creates its own guest stack, it ignores rlimit. There's an option for changing the size.
<1> The default is relatively small (512k)
<4> pbrook... i'll redefine my question
<5> pbrook: i think i should try that. is it in qemu manual ?
<4> mac os x is supported
<1> nerochiaro: Yes.
<4> as in running from within
<4> as an mac os x app
<5> pbrook: thanks. trying
<1> pixiept: Should work, yes.
<4> i'm talking on accelerater plugins
<4> accelerator
<1> Oh, probably not.
<4> :S
<0> gah
Return to
#qemu
or
Go to some related
logs:
darkstone ISO
#math
modify a bootable ISO
#debian
irongland
authProg sasl
linux how to turn off cron
vt1211: Unknown symbol vid_from_reg
ubuntu sudo route add default gw dev ppp0
gtkgaim.dll
|
|