С# принципиально не переносимый?

Есть две проблемы в отношении «переносимости»:

1. Can an practical implementation of a language be produced for various platforms
2. Will a program written in a language be expected to run correctly on various platforms without modification

Чем сильнее гарантии, предоставляемые языком, тем труднее будет перенести его на различные платформы (некоторые гарантии могут сделать невозможным или нецелесообразным реализовать язык на некоторых платформах), но тем больше вероятность того, что программы, написанные на этом языке, будут работать без изменений на любой платформе, для которой существует поддержка.

Например, большая часть сетевого кода основана на том факте, что (на большинстве платформ) символ без знака состоит из восьми битов, а 32-битное целое число представлено четырьмя символами без знака в восходящей или нисходящей последовательности. Я использовал платформу, где char был 16 бит, sizeof(int)==1 и sizeof(long)==2. Автор компилятора мог бы заставить компилятор просто использовать нижние 8 бит каждого адреса или мог бы добавить много дополнительного кода, чтобы запись указателя 'char' смещала адрес вправо на один бит (сохраняя младший бит), читая адрес, обновить старшую или младшую половину на основе сохраненного младшего бита адреса и записать его обратно. Любой из этих подходов позволил бы сетевому коду работать без изменений, но сильно затруднил бы полезность компилятора для других целей.

Некоторые гарантии среды CLR означают, что ее нецелесообразно реализовывать на любой платформе с размером атомарной операции менее 32 бит. И что? Если микроконтроллеру требуется больше, чем несколько десятков килобайт пространства для кода и оперативной памяти, разница в стоимости между 8-битным и 32-битным процессором довольно мала. Поскольку никто не собирается запускать какую-либо вариацию CLR на части с 32 КБ пространства кода и 4 КБ ОЗУ, какая разница, сможет ли такой чип удовлетворить свои гарантии.

Кстати, я думаю, что было бы полезно иметь разные уровни функций, определенные в спецификации C; многие процессоры, например, имеют 8-битные символы, которые могут быть собраны в более длинные слова с помощью союзов, и существует много практического кода, который использует это. Было бы хорошо определить стандарты для компиляторов, которые работают с такими вещами. Я также хотел бы видеть больше стандартов на нижнем уровне системы, делая некоторые улучшения языка доступными для 8-битных процессоров. Например, было бы полезно определить перегрузки для функции, которая может принимать 16-разрядное целое число, вычисляемое во время выполнения, 8-разрядную переменную или встроенную развернутую версию с константой. Для часто используемых функций может быть большая разница в эффективности между ними.

Нетрудно гарантировать атомарность с помощью проверок во время выполнения. Конечно, вы не будете столь производительны, как могли бы быть, если бы ваша платформа поддерживала атомарное чтение и запись, но это компромисс платформы.

Итог: C# (основной язык, не считая некоторых API для конкретных платформ) так же переносим, ​​как и Java.

Будущее произошло вчера, C# на самом деле портирован на большое количество встроенных ядер. .NET Micro Framework — типичный сценарий развертывания. Номера моделей, которые я вижу в качестве собственных целей, — это AT91, BF537, CortexM3, LPC22XX, LPC24XX, MC9328, PXA271 и SH2.

Я не знаю точных деталей реализации их основного набора инструкций, но я совершенно уверен, что это все 32-битные ядра, и некоторые из них являются ядрами ARM. Написание многопоточного кода для них требует минимальной гарантии, и атомарные обновления для правильно выровненных слов — одна из них. Учитывая поддерживаемый список и то, что 4-байтовые атомарные обновления для выровненных слов тривиальны для реализации на 32-битном оборудовании, я верю, что все они действительно его поддерживают.

Вот для чего нужен CLI. Я сомневаюсь, что они сертифицируют реализацию, если она не соответствует требованиям. В общем, C# переносим на любую платформу, на которой он есть.

Чрезмерное ослабление гарантий ради переносимости наносит ущерб цели переносимости. Чем сильнее гарантии, тем ценнее мобильность. Цель состоит в том, чтобы найти правильный баланс между тем, что вероятные целевые платформы могут эффективно поддерживать, и гарантиями, которые будут наиболее полезными для разработки.