0

I'm currently working with Sparc V8 architecture Atmel based boards. So, for unit level testing, i'm doing in on my linux machine (Intel x86). Since, x86 is a little endian machine where as Atmel Processor is a big endian processor, all my memory pointers are going for a toss. Will porting a VM with Solaris (Sparc- Big endian OS) and running test help?

Gaurav Agarwal Garg
  • 113
  • 1
  • 1
  • 9
  • Memory on the SPARC system and memory on the Intel system are on different computers, so i don't see why this is a problem. Are you trying to print a memory address on one system and imagine the corresponding thing will be stored on the other? It's highly unlikely that will be the case. Use endian conversion macros for debugging. – barefootliam Apr 22 '19 at 08:34

2 Answers2

0

Why don't you just install linux on your sparc machine? Linux already has a port for sparc, and it ought to still work on a v8 cpu as the maintainers are pretty careful to keep old stuff working.

Rob Gardner
  • 201
  • 1
  • 4
  • What would that solve? The hardware would still be big-endian. – Andrew Henle Mar 05 '17 at 02:21
  • Sparc Machine is nothing but an Atmel ATF69 Processor which is presently used as Bare Metal, so porting a linux wont help me their. Most of my testing (especially unit test) will be on my desktop i.e Intel x86. Problem is the difference of byte ordering so all my memory operations goes for a toss. – Gaurav Agarwal Garg Mar 05 '17 at 14:29
  • Guess I don't understand what you are trying to do as your question is pretty confusing. What do you mean "will porting a VM with solaris"? You mean run solaris in a vm on intel? So is your goal to run on sparc or to run on intel? Or you just want to test on intel? Can you clarify? I also don't understand the expression "going for a toss". What is the actual problem? If you write code that is endian neutral then it should work on both architectures and you should be able to test your code on intel then run it later on sparc. Give more information and I can try to help. – Rob Gardner Mar 05 '17 at 17:15
  • You can't run a big endian OS on intel, even in a vm, if that's what you're asking. – Rob Gardner Mar 05 '17 at 17:17
  • @RobGardner : Answer to the questions: Port VM with Solarsis means i'll have a VM running on Solaris on my x86 Intel Machine. My goal is to do my unit testing independent of sparc i.e do it on intel x86. Due to endianess my application saves data like 0x1234 in sparc and in x86 it will be 0x3412, so that is what i'm calling it "Toss" . Writing endian neutral code isn't possible as i'm playing around with a lot of arrays, pointers. – Gaurav Agarwal Garg Mar 08 '17 at 10:40
  • Is there a way out to make it happen?if running VM won't help? @RobGardner – Gaurav Agarwal Garg Mar 08 '17 at 10:45
  • Endianness should only be a problem if you are using mass storage or networking to exchange data with a system using a different endianness. Code itself can usually be made endian neutral through the use of appropriate macros etc. Could you give an example of some code that you are having trouble with? Arrays and pointers don't make this impossible, plenty of code has to do this already, ie, kernel driver networking and filesystem code. – Rob Gardner Mar 09 '17 at 17:23
  • 2
    Unfortunately, since x86 is little endian, anything you run in a virtual machine will also be little endian, so I don't think this is an option. By far the easiest thing to do is to make a bigger effort to make your code endian neutral. – Rob Gardner Mar 09 '17 at 17:23
  • Even if you save data in storage or send it over a network, the code should decide on the endianness of the storage, then endian neutral code can make the correct interpretation of it using functions/macros that depend on the platform you are running on. For example: – Rob Gardner Mar 09 '17 at 17:24
  • For example, look at the linux kernel macro be32_to_cpu or the libc macros ntohl etc, which converts between network byte order and host order. On each platform, these are defined to either swap bytes or not, depending on the endianness of the host. – Rob Gardner Mar 09 '17 at 17:31
  • @RobGardner: It's entirely possible for a VM designed for 80x86 to emulate a big-endian system (and possible to do the opposite - emulate a little-endian guest on a big-endian host). It just means that the VM has to take care of byte swapping (which would effect performance, but should not effect correctness). – Brendan Mar 11 '17 at 09:48
  • You are ignoring the real issue that the SPARC platforms tend to seg fault on every memory pointer that is out of bounds by 1 byte, to a far greater degree than x64 complied code seems to. Unless you are saving binary data and then loading it on another machine, endianess itself is seldom an issue. The difference of 64bit ints and unaligned reads being legal on x64 causes far more trouble. – camelccc Mar 11 '17 at 09:51
  • @Brendan, perhaps it's possible, but it's not really a practical option. It would be a huge amount of work, and it seems to me that you'd have to emulate every load and store instruction for it to work. But I admit I haven't thought it through. I am interested to hear your ideas if you've given it more thought. – Rob Gardner Mar 11 '17 at 16:26
  • 1
    @camelcc, true that x86 has lax alignment rules, and this has allowed programmers to get away with buggy code, which then crashes when run on sparc. If you insist on casting a pointer to other types (ie, one that points to an object of different size), then you'll have problems. But such code has undefined behavior, according to the C spec. See section 6.3.2.3, paragraph 7 in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf – Rob Gardner Mar 11 '17 at 16:50
  • @RobGardner: Whenever the guest and host CPUs have different instruction sets and/or opcodes, you have to emulate every instruction anyway (either using pure interpreting, or JIT). – Brendan Mar 12 '17 at 07:46
0

You can't run SPARC version of Solaris in Intel VM, it just won't boot.

The only exception is QEMU emulator, but it'll likely be very slow

myaut
  • 11,174
  • 2
  • 30
  • 62
  • "Slow" may not matter and in some cases can be beneficial. E.g. one of the reasons I use Bochs regularly is because I want to know that my code is fast enough to be usable on ancient (<20 MHz) CPUs. Modern CPUs are so fast that it's hard to notice extreme performance disasters. – Brendan Mar 12 '17 at 07:56
  • @Brendan, you're probably running DOS in it. I've read somewhere that Windows XP (which is more modern than DOS) takes a day only to boot in Bochs. I doubt that it is acceptable timings – myaut Mar 12 '17 at 08:44
  • I'm running my code (it's operating system code, and at times includes things like full 3D software rendering). The "slowdown factor" is around 80 (e.g. with a 3000 MHz host CPU you'd emulate a 37.5 MHz guest CPU). Don't believe whatever you think you might've read. If it took Windows XP 1 day to boot in Bochs on a modern 3 GHz machine then it'd take Windows XP a few hours to boot on a ~350 MHz machine it was originally designed to be able to run on. However a lot of "time consumed during boot" is disk IO which isn't effected by "slowdown factor". – Brendan Mar 12 '17 at 09:12