В настоящее время я работаю с платами на базе Atmel с архитектурой Sparc V8. Итак, для тестирования на уровне модулей я использую свою Linux-машину (Intel x86). Поскольку x86 - это машина с прямым порядком байтов, тогда как процессор Atmel - процессор с прямым порядком байтов, все мои указатели памяти теряются. Поможет ли перенос виртуальной машины с Solaris (Sparc - Big endian OS) и запуск теста?
Запуск виртуальной машины с ОС Solaris (архитектура Sparc) на процессоре Intel x86 разрешить прямой порядок байтов в обратный порядок байтов?
comment
Память в системе SPARC и память в системе Intel находятся на разных компьютерах, поэтому я не понимаю, почему это проблема. Вы пытаетесь напечатать адрес памяти в одной системе и представить себе, что соответствующая вещь будет сохранена в другой? Маловероятно, что это так. Используйте макросы преобразования байтов для отладки.
- person barefootliam schedule 22.04.2019
Ответы (2)
Почему бы вам просто не установить Linux на свою машину с sparc? В Linux уже есть порт для sparc, и он должен работать на процессоре v8, так как сопровождающие очень осторожны, чтобы старые вещи работали.
person
Rob Gardner
schedule
03.03.2017
Что это решит? Аппаратное обеспечение по-прежнему будет прямым порядком байтов.
- person Andrew Henle; 05.03.2017
Sparc Machine - это не что иное, как процессор Atmel ATF69, который в настоящее время используется как Bare Metal, поэтому перенос Linux не поможет мне их. Большая часть моих тестов (особенно модульных) будет проводиться на моем рабочем столе, то есть Intel x86. Проблема в различии порядка байтов, поэтому все мои операции с памятью идут наперекосяк.
- person Gaurav Agarwal; 05.03.2017
Думаю, я не понимаю, что вы пытаетесь сделать, так как ваш вопрос довольно запутанный. Что вы имеете в виду, портируя виртуальную машину с Solaris? Вы имеете в виду запускать solaris в vm на intel? Итак, ваша цель - работать на Sparc или на Intel? Или вы просто хотите по инфу потестить? Вы можете уточнить? Я также не понимаю выражения «бросить». В чем проблема? Если вы пишете код с нейтральным порядком байтов, он должен работать на обеих архитектурах, и вы сможете протестировать свой код на Intel, а затем запустить его позже на sparc. Дайте больше информации, и я постараюсь помочь.
- person Rob Gardner; 05.03.2017
Вы не можете запустить ОС с прямым порядком байтов на Intel, даже в виртуальной машине, если это то, о чем вы спрашиваете.
- person Rob Gardner; 05.03.2017
@RobGardner: Ответьте на вопросы: Port VM с Solarsis означает, что у меня будет виртуальная машина, работающая на Solaris на моей машине Intel x86. Моя цель - провести модульное тестирование независимо от sparc, то есть на Intel x86. Из-за endianess мое приложение сохраняет данные типа 0x1234 в sparc, а в x86 это будет 0x3412, поэтому я называю это Toss. Написание нейтрального кода endian невозможно, так как я играю с множеством массивов, указателей.
- person Gaurav Agarwal; 08.03.2017
Есть ли способ сделать это? Если запуск виртуальной машины не поможет? @RobGardner
- person Gaurav Agarwal; 08.03.2017
Порядок байтов должен быть проблемой только в том случае, если вы используете массовое хранилище или сеть для обмена данными с системой, использующей другой порядок байтов. Сам код обычно можно сделать нейтральным с порядком байтов с помощью соответствующих макросов и т. Д. Не могли бы вы привести пример кода, с которым у вас возникли проблемы? Массивы и указатели не делают это невозможным, для этого уже нужно много кода, например, сетевой драйвер ядра и код файловой системы.
- person Rob Gardner; 09.03.2017
К сожалению, поскольку x86 является прямым порядком байтов, все, что вы запускаете на виртуальной машине, также будет иметь обратный порядок байтов, поэтому я не думаю, что это вариант. Безусловно, самое простое - приложить больше усилий, чтобы сделать ваш код нейтральным.
- person Rob Gardner; 09.03.2017
Даже если вы сохраняете данные в хранилище или отправляете их по сети, код должен определять порядок байтов хранилища, тогда нейтральный код может правильно интерпретировать его с помощью функций / макросов, которые зависят от платформы, на которой вы работаете. Например:
- person Rob Gardner; 09.03.2017
Например, посмотрите на макрос ядра linux be32_to_cpu или макросы libc ntohl и т. Д., Которые преобразуют между сетевым порядком байтов и порядком хоста. На каждой платформе они определены для обмена байтами или нет, в зависимости от порядка байтов хоста.
- person Rob Gardner; 09.03.2017
@RobGardner: Виртуальная машина, разработанная для 80x86, вполне может имитировать систему с прямым порядком байтов (и можно сделать наоборот - эмулировать гостя с прямым порядком байтов на хосте с прямым порядком байтов). Это просто означает, что виртуальная машина должна позаботиться об обмене байтами (что повлияет на производительность, но не должно повлиять на правильность).
- person Brendan; 11.03.2017
Вы игнорируете реальную проблему, заключающуюся в том, что платформы SPARC имеют тенденцию выделять ошибки для каждого указателя памяти, выходящего за границы на 1 байт, в гораздо большей степени, чем это может показаться в коде, совместимом с x64. Если вы не сохраняете двоичные данные, а затем загружаете их на другую машину, порядок байтов редко является проблемой. Разница между законными 64-битными целыми числами и невыровненными чтениями на x64 вызывает гораздо больше проблем.
- person camelccc; 11.03.2017
@Brendan, возможно, это возможно, но это не совсем практичный вариант. Это был бы огромный объем работы, и мне кажется, что вам придется эмулировать каждую загрузку и сохранять инструкции, чтобы она работала. Но признаю, что не продумала. Мне интересно услышать ваши идеи, если вы обдумали их подробнее.
- person Rob Gardner; 11.03.2017
@camelcc, правда, что x86 имеет слабые правила выравнивания, и это позволило программистам избежать ошибок в коде, который затем дает сбой при запуске на sparc. Если вы настаиваете на приведении указателя к другим типам (то есть к тому, который указывает на объект другого размера), у вас возникнут проблемы. Но такой код имеет неопределенное поведение, согласно спецификации C. См. Раздел 6.3.2.3, параграф 7 в open-std .org / jtc1 / sc22 / wg14 / www / docs / n1256.pdf
- person Rob Gardner; 11.03.2017
@RobGardner: всякий раз, когда гостевой и хост-процессоры имеют разные наборы инструкций и / или коды операций, вы все равно должны эмулировать каждую инструкцию (либо используя чистую интерпретацию, либо JIT).
- person Brendan; 12.03.2017
Вы не можете запустить SPARC-версию Solaris в Intel VM, она просто не загружается.
Единственное исключение - эмулятор QEMU, но он, скорее всего, будет очень медленным
person
myaut
schedule
11.03.2017
Медленное может не иметь значения, а в некоторых случаях может быть полезным. Например. Одна из причин, по которой я регулярно использую Bochs, заключается в том, что я хочу знать, что мой код достаточно быстр, чтобы его можно было использовать на старых (<20 МГц) процессорах. Современные процессоры настолько быстры, что трудно заметить резкое падение производительности.
- person Brendan; 12.03.2017
@Brendan, вы, наверное, используете в нем DOS. Я где-то читал, что Windows XP (более современная, чем DOS) загружается только в Bochs за день. Сомневаюсь, что это приемлемые сроки
- person myaut; 12.03.2017
Я запускаю свой код (это код операционной системы, который иногда включает такие вещи, как полный программный рендеринг 3D). Фактор замедления составляет около 80 (например, с центральным процессором с частотой 3000 МГц вы должны эмулировать гостевой процессор с частотой 37,5 МГц). Не верьте тому, что, по вашему мнению, вы могли прочитать. Если для загрузки Windows XP в Bochs на современной машине с тактовой частотой 3 ГГц требовалось 1 день, то Windows XP потребовалось бы несколько часов для загрузки на машине с частотой ~ 350 МГц, которая изначально была разработана для работы. Однако во время загрузки много времени тратится на ввод-вывод диска, на который не влияет фактор замедления.
- person Brendan; 12.03.2017
