Consider changing the processor named "WE" to "WE32100" about ghidra_we HOT 8 OPEN

I'll look into it. The big question i guess is where are the differences? Instruction encoding, memory layout, memory mapped registers, etc...

Can probably get away with keeping WE, with multiple cspec/pspec/slaspec files (maybe additional additional sinc depending on change in instructions) and include more entries in the ldefs file.

from ghidra_we.

Unfortunately, documentation for the WE32200 is hard to find. I have a paperback copy of the processor manual, which as far as I know has never been scanned :( Primary differences are new instructions, expanded addressing modes, 32 registers vs 16, and optional unaligned word access. I should be clear that it's not a very high priority for me! I don't know of any commercial AT&T software compiled for the WE32200. It is fully backward compatible with the WE32100, so they just compiled for the WE32100 and treated the WE32200 as a faster WE32100.

from ghidra_we.

By the way, is there a better way to get in touch with you outside of opening issues? I wanted to pass along an interesting tidbit.

I've hacked Ghidra to load AT&T's two COFF file formats. For Intel 80186 code (firmware used by expansion cards), they used little-endian COFF files with big-endian headers. For WE32100 code, they used big-endian COFF files. Check out the branch "we-coff" here: https://github.com/sethm/ghidra/tree/we-coff

If you want some real binary files to test with, I have them here: https://archives.loomcom.com/3b2/scsi/

This is great progress, so far. I was able to load the WE32100 SCSI driver using your WE processor! I added an "opinion" file, but I haven't yet checked that in yet.

from ghidra_we.

I don't really have much of social media besides reddit, same name, and no slack/discord. Guess I should make an acct on some RE based channel

Thanks for the sample, I used the bin in simh/3B2

did they reuse the old-style MS DOS magic value?

from ghidra_we.

@sethm pushed commit to try and fix a few things, hopefully didn't break too much, but stuff was def wrong (only slaspec/sinc, haven't build up the willpower to open cspec/pspec). Seeing any breakage probably means I'm moving in the right direction, let me know if you find something specific that you can ref an addr in the scsi or the simh binaries

http://www.bitsavers.org/pdf/westernElectric/

is WE_32-Bit_Microprocessors_and_Peripherals_Aug87.pdf by chance the book you're talking about for 32200?

from ghidra_we.

@mumbel Analysis is failing on the file scsi-we32k-driver, I'm not sure why. I still have a lot to learn about Ghidra and Sleigh before I can really contribute much. I have opened a pull request with a few very minor additions to the project, but I haven't touched the Sleigh file yet.

The book I have is "WE32200 Microprocessor Information Manual" (November 1987, Select Code 307-705). I would like to scan it, but I will either need to build a book scanner, or cut off the spine, and I really don't want to cut the spine unless I absolutely have to.

from ghidra_we.

Def don't ruin it, the PDF I found looks like it has everything needed for 32200 support

from ghidra_we.

@sethm I did a bit of file renaming, let me know if that seems closer to what you were hoping for.

Also trying to tweak some of the SLEIGH for some of my (mis)interpretations of the manual. Compiler sure hates life now though, so you may want to wait to pull or you want to try messing with it :D ... I'll need to build a debug compiler and get this module running in eclipse (just using 9.1.2 currently). The extended addressing mode still isn't clicking so destinations with that are still broken

from ghidra_we.