Сколько из операционной системы могло быть записано в, скажем, Python? [закрытый]

Указатель NULL - это тот, который указывает на никуда. Когда вы разыскиваете указатель p, вы говорите «дайте мне данные в месте, хранящемся в« p ». Когда p является нулевым указателем, местоположение, хранящееся в p, является nowhere, вы говорите «Дайте мне данные в месте« нигде ». Очевидно, он не может этого сделать, поэтому он выбрасывает NULL pointer exception.

В общем, это потому, что что-то не было правильно инициализировано.

14
задан casperOne 5 April 2012 в 13:16
поделиться

11 ответов

Технически, любой из него мог быть, если Вы пишете компилятор, чтобы сделать так. Ose были сделаны в Java (JNode).NET (MOSA, Особенность, SharpOS, Космос), Haskell (ДОМ), Python (Unununium), и т.д.

Редактирование: Я вижу много людей, говорящих об очень самом низком уровне, являющемся областью, где это не могло быть сделано; это не верно.

нет никакой причины, что компилятор для X языков не может быть расширен, чтобы обработать любую низкоуровневую операцию и выставить его языку. Вся функциональность может быть достигнута с любого языка, это - просто вопрос выбора правильного инструмента для задания. Иногда это - Python, иногда это - C, иногда это - блок.

Смотрят на проекты как Космос и SharpOS для наблюдения чистого высокоуровневого OS Done Right (TM).

21
ответ дан 1 December 2019 в 06:32
поделиться

Один интересный результат от Особенности, Вам не нужен MMU (блок управления памятью) в ЦП больше, так как всем кодом пространства пользователя "управляют". Я видел это выгодное во встроенных сценариях, с помощью non-MMU Linux и к тому же написал сценарий приложений.

3
ответ дан 1 December 2019 в 06:32
поделиться

Дом - Операционная система Пользователя Haskell и Среда . Это является даже загрузочным в VM, и Вы могли играть с ним.

Источники очень читаемы, IMO.

3
ответ дан 1 December 2019 в 06:32
поделиться

См. Рода / OpenGenera для примера ОС, записанной в Lisp, который на самом деле использовался долгое время на LispMachines.
Haskell имеет Дом .

3
ответ дан 1 December 2019 в 06:32
поделиться

Вне ядра (и этим, я имею в виду ядро, стиль микроядра), и чего-то для компиляции времени выполнения для каждого из упомянутых динамических языков примерно что-либо и все МОГЛИ быть при создании собственной операционной системы. Это просто не практично. Heck, init.d записан, прежде всего, в sh насколько я знаю. Но sh, в то время как не мощный, ОЧЕНЬ легко и насколько я знаю, эффективный в том, что это делает. Высокоуровневые языки как Python, Perl, и т.д., могли обработать его прекрасный, но это будет намного медленнее, и взяло бы намного больше памяти для экземпляров интерпретаторов.

Это возможно, это просто не практично.

2
ответ дан 1 December 2019 в 06:32
поделиться

Пока язык программирования имеет способность управлять двоичными файлами, Вы могли записать полную ОС на конкретном языке. Нельзя сказать, что это легко, или практично. Это просто имеет смысл, что, если Ваш выбранный язык может управлять двоичным файлом, то можно пойти как низкий уровень, как Вам нужно.

2
ответ дан 1 December 2019 в 06:32
поделиться

Python исходно не обеспечивает конструкции для разговора непосредственно с аппаратными средствами, как необработанные указатели для ввода-вывода с отображенной памятью и много других конструкций, обеспеченных C/ASM. Однако существует доказательство, что большинство все в ОС может быть записано на более абстрактном языке; Особенность ОС от Microsoft записана почти исключительно в вариантах C#. Существует чрезвычайно небольшое количество C/ASM, чтобы сделать обработчиков прерываний и такой, но во всем остальном, включая то, что большинство из нас считает "ядром", можно выполнить по существу любой полный по Тьюрингу язык.

нужно отметить, что выбор Особенности реализовать эти конструкции низкого уровня в C/ASM не должен быть интерпретирован как фундаментальное ограничение синтаксиса или другие аспекты высокоуровневых языков. Можно было, конечно, сделать вариант Python, который испустил и имел дело соответственно с необходимым ассемблерным кодом.

2
ответ дан 1 December 2019 в 06:32
поделиться

Трудно вообразить ядра / драйверы устройств и т.д. записанный в (например, Python) - управление памятью было бы чем-то вроде головной боли.

, С другой стороны, почти весь код пространства пользователя мог быть. В соответствии с Linux, нет никакого требования, чтобы "init" быть двоичным файлом собственного машинного кода - это мог быть сценарий Python или что-то, без проблем.

1
ответ дан 1 December 2019 в 06:32
поделиться

Я сказал бы, что это не возможно. Ответы на этот вопрос продолжают относиться к изменениям в языке или использовать язык для сгенерированного низкого уровня (ядро) код. Это просто использует один язык для записи другого языка. В то время как я соглашаюсь, что оба из них позволили бы Вам затем писать операционную систему, я буду затем утверждать, что это - теперь не тот же язык. Так, операционная система могла быть записана на многих различных языках, но не каждом языке (без изменения, или язык передачей) может использоваться для записи операционной системы.

ответ украшения на исходный вопрос - почти все, но не все. Единственное принятое значение слова является языками, которые могут получить доступ к инструкциям по уровню процессоров.

0
ответ дан 1 December 2019 в 06:32
поделиться

"cleese" - операционная система, почти полностью написанная на Python

2
ответ дан 1 December 2019 в 06:32
поделиться

I'm surprised nobody has mentioned Java hardware. It should be an inspiration for us to further the evolution of hardware by creating an even higher level processor.

There's another project I just found called "Pycorn".

If there was a Python bytecode processor, it would be feasible to make a fast operating system in 100% Python. The processor could implement the entire CPython bytecode, or anything that is compatible with the Python language (But not C modules!). The processor would have to handle reference counting, classes, and objects. Native hashing for dicts would be very helpful, all the complex data structure manipulations which Python currently needs in software should be done purely in hardware. There would be no concept of pointers, which I see as a prime motivation for building such a processor, as it would be impossible to smash the stack.

Everything would be objects! The kernel itself would call methods on the memory object, although you wouldn't need to touch it much since the hardware will handle allocation and garbage collection anyways. Interrupt handlers can simply be set to python methods. MSRs, caches, debug registers, and I/O ports are objects.

There's a interesting discussion about implementing Python on an FPGA here.

On another note, (pertaining to a Python O/S on a non-Python processor) to the people claiming you can't make inline assembly Pythonic, it's pretty simple to just emit assembly from an abstraction, ex:

asm = MetaASM()
asm.r1 = 1234
asm.r2 = r1 + 5
asm.io.out(r1)

You could switch to architecture specific assembly for performance needs or architecture specific operations / registers when necessary:

asm = ASM("IA-32")
asm.xor(asm.eax, asm.eax)
asm.cr0 = asm.eax
asm.invtlb
asm.fs.0x00123456 = asm.eax
asm.al = 123
asm.dword.ptr.eax = 1234 # mov dword ptr [eax], 1234
asm.push(asm.eax)

CorePy comes to interest on this topic.

7
ответ дан 1 December 2019 в 06:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: