devoz@pinocchio.encore.com (Joe DeVincentis) (11/10/89)
Hello! I would like to contact any of you m88k users who have found the motorola m88k simulator useful..... Maybe we could share some bug-fixes, or whatever. (Yes, bugs exist). I write diagnostic software, and find that the simulator allows me to map in board registers, (CSRS), diag memory, etc, and work out my assembler language stuff fairly well. I have also started the hardware engineers using it as they run assembler on processor board simulations, and if they get a chance to debug the code first, they don't waste time in the hardware simulation, which is much slower, and more expensive! Anyone else out there use this thing? (I am using version 4.0, running it on a little endian Multimax, which presents some problems which we are trying to fix...).... devoz@encore.com
hunter@oakhill.UUCP (Hunter Scales) (11/13/89)
devoz@pinocchio.encore.com (Joe DeVincentis) writes: >Hello! > I would like to contact any of you m88k users who have found the >motorola m88k simulator useful..... Maybe we could share some bug-fixes, >or whatever. (Yes, bugs exist). >devoz@encore.com m88ksim is a Motorola-supported product. If you find bugs in the package, please report them to oakhill!m88kbugs@cs.utexas.edu and we will have them fixed. Motorola Semiconductor Inc. Hunter Scales Austin, Texas {harvard,utah-cs,gatech}!cs.utexas.edu!oakhill!hunter #include <disclaimer.h> -- Motorola Semiconductor Inc. Hunter Scales Austin, Texas {harvard,utah-cs,gatech}!cs.utexas.edu!oakhill!hunter #include <disclaimer.h>
andrew@frip.WV.TEK.COM (Andrew Klossner) (11/14/89)
We used Moto's 88k simulator for awhile, but ended up abandoning it and
writing our own so as to get good execution speed. It runs 88k code at
about 0.2 MIPS on a 20MHz 68020-based system. The front-end is the dbx
debugger. We used it to get our diagnostics, kernel, and init and
single-user shell up.
Details are in an upcoming Usenix paper by Rob Bedichek. Source code
is available gratis to any member of the 88open Consortium who has a
Berkeley source license.
-=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP]
(andrew%frip.wv.tek.com@relay.cs.net) [ARPA]devoz@pinocchio.encore.com (Joe DeVincentis,EFD TR 75S TR 4S TL 1S TL,2622,7568004) (11/14/89)
From article <5321@orca.WV.TEK.COM>, by andrew@frip.WV.TEK.COM (Andrew Klossner): > We used Moto's 88k simulator for awhile, but ended up abandoning it and > writing our own so as to get good execution speed. It runs 88k code at > about 0.2 MIPS on a 20MHz 68020-based system. > -=- Andrew Klossner (uunet!tektronix!frip.WV.TEK!andrew) [UUCP] We run the simulator on a system that has 6 "8.5" mip NS32532 chips. I haven't found the speed to be a big issue. It also doesn't require a 68020. It does like big endian though :-(. I particularly like the preset capability, which is essentially running simulator commands from a file at startup. I have multiple CPUS to control, and they play certain roles based on CSR values at startup. With this simulator, I can run a single CPU through the code, modify registers, memory, the IP, and test the actual code without conditional compilation... all from a "command" file! Here is a sample of the command file [lots of memory mapping statements deleted] md ip; di ; display 4 instructions from the current ip br init_checksum_label ; set a break point g ; go md ip; di ; display 4 instrucs at breakpoint br uart_test ; set another break sym stack_setup ; show address of symbol "stack_setup" rm ip stack_setup . ; modify the IP to this address md ip; di ; display 4 more instrucs, (I like to see whats happ) g ; go rm ip ram_address_test . ; get up to the current test code md ip; di ; show instrucs br ram_address_ok ; set break on completion br data_address_failure ; or failure g ; go So, you see from this example, that I can control the flow of the code to test what I want with very little effort, NO recompilation, and I don't have to sit through a couple of minutes of memory scan tests, or rom checksum tests, (things we do in our startup of the diags).... With the code developed for multiple CPUS, I bring the board up to certain points, then force values into registers which makes it look like the other CPUS are actually doing what they should be, testing multiple CPU software before we have the multiple CPUS around. Neat stuff. Makes my job more fun too. Moto would have to make some changes to their simulator to let everyone do this. The rm (register modify) command, and I assume the memory modify command , read input from the stdin, so I had to hack code in to check the number of arguments for the current command. If there are a complete set of args, I use the args as opposed to reading stdin. Anyway, said more than I want to. I am working on a list of things that I had to do (other than what we did for endian changes, as thats another story), to make the simulator more useful for the Moto simulator person(s). Joe DeVincentis devoz@whateverthemailheadersays.com
crisp@mips.COM (Richard Crisp) (11/21/89)
to work. would you please drop me a line at 408 991 0477 to inform me of your email address? -Richard Crisp crisp@mips.com -- Just the facts Ma'am
crisp@mips.COM (Richard Crisp) (11/21/89)
I can't get the email addressing to work. Please drop me a line Mr. Scales to inform me of your email address at oakhill. 408 991 0477, crisp@mips.com -Richard Crisp -- Just the facts Ma'am