И нет платформ, ну кроме музея, где байт код JVM был бы родным для процессора.
Байт код — родной для виртуальной машины JVM. Ваши требования «нативности» — волюнтаризм, к градации «компиляция-не компиляция» не имеют отношения.
Потому есть различие — нативный код — не нативный код. Есть ли промежуточная прослойка, транслирующая некий код в нативный или ее нет.
И есть итоговая разница в производительности/ресурсах, требуемых для нее.
Упор на производительность — это демагогия, см. пример с компиляцией и Bochs. Компилируемый язык или нет — не зависит от того, нативный ли код на выходе. Если вы, условно, транслируете программу на платформе Win32 / x86 под Linux/Itanium, то вы выполняете компиляцию, хоть тресни. Кросс-компиляцию, но тем не менее.
Мне надоело.
Про кросс-компиляторы — в учебник.
Для начала разберитесь в определениях, которые отличаются от ваших хотелок, потом вернемся к разговору.
Юнибас — это не показатель. Для задач управления технологическим оборудованием вполне может это все потребоваться.
Технология, которая позволяет экономить время процессора (я имею в виду не сам ЮБ а опцию прямой перегонки между ее узлами) — не показатель того, что экономится время процессра? Ок.
(миллион операций с плавающей точкой по тем временам это было очень серьезно).… То есть нормальный режим — задача считается, потом что-то печатает, потом запускается другая задача.
Еще бы — вторая после Крея по производительности на то время. Да, пакетный режим — он такой. Но многотерминальные системы с соответствующей ОС там ведь тоже были…
PDP-11, она же СМ-4, СМ-1420 — это мини-компьютер по тем временам. Там тоже не было задачи обеспечить экономию ресурса ЦП
Не согласен. Если бы это было так, то у этой серии бы не было юнибаса с прямой перегонкой (не только DMA) между устройствами. Да и скромная производительность ЦП не позволяет говорить о том, что этот ресурс не надо экономить.
Если бы процессор там реагировал на каждое нажатие кнопки, то он (при таком быстродействии) только этим и занимался бы.
Читал, что в комплексе БЭСМ-6 (другого класса машина, но не суть) использовались АЦПУ, генерирующие прерывания при печати в соответствии с вращением алфавитного барабана, в котором, по идее, должно быть 64-128 позиций, т.е. 64-128 прерываний за один поворот барабана, который вращается много быстрее, чем 1 об в минуту. Хороший пример «неумного» устройства.
Так что посимвольной передачи в тех терминалах не было в принципе. По нажатию на кнопку процессор получает сигнал, что надо считать данные с терминала и запрашивает чтение. Причем, читать может даже не весь экран, а, например, только модифицированные поля, если это форма ввода данных. При этом все чтение/запись идет через DMA, так что и на это процессор не отвлекался.
И тем не менее, в DECовских машинах такое чтение было возможным, несмотря на наличие DMA. Это вопрос гибкости. Но припоминаю рассказы старших товарищах о проблемах с реализацией игр как раз из-за терминальной стойки на ЕС.
В результате, на машинке с 800К операций в секунду и 1 мегабайтом памяти вполне комфортно могли работать (набирать текст, писать программы) 20-30 человек.
На СМ-1420, пусть н с 1, но с 2-4 мегабайтами памяти и соответствующим мультиплексором, тоже могли работать 20-30 человек.
К сожалению, «поделиться» в сфере IT у русских на последнем месте. Я не исключение. Ведь из затраченного времени хочется извлечь прибыль, а в России не выжить без прибыли, это не Норвегия
Только у посредственностей, которым тяжело дается изучение чего бы то ни было. Для остальных уже изученное — пройденный этап, они уже впереди, ведь они прошли это, поэтому могут делиться.
Просто при чтении на самом деле непонятно — то ли это выделение, то ли шутка, то ли правка (как некоторые иногда делают — при указании ошибки не удаляют ее, а маркируют зачеркиванием). Оно, конечно, ваше дело, но сходу непонятно.
А если мы считаем таракана птицей, то что?
Сочтут идиотом
Нет, это корректное допущение. У нас гипотетически может быть «железный» процессор, работающий с байт-кодом. Если у вас есть виртуальная машина, скажем, bochs или что-то аналогичное, работающее с x86 кодом, который является продуктом компилтора gcc, вы же не будете говорить, что мы имеем дело не с компиляцией, поскольку код исполняется виртуальной машиной.
Но есть и интерпретаторы байт кода (другого, не JVM), которые медленные как все прочие интерпретаторы.
И что? Машинный код многих процессоров тоже интерпретируется.
Помню свои ощущения, когда впервые вступил в живой разговор с начальником-американцем. До этого общались письменно, общались устно с коллегами-неамериканцами. А тут… такое забавное ощущение, когда человек что-то тебе говорит, говорит, говорит, ты понимаешь все слова по отдельности, а вот фразу — нет. Ни по логике построения, ни просто по скорости. И стоишь так, понимаешь, что он тебя что-то спросил — чисто по интонации. Соображаешь, что же от тебя хотят. Ничего, постепенно втянулся, научился воспринимать native speaker'ов на слух. Но первая встреча с носителем — как удар по голове.
Это терминологический спор, скучный как не знаю что. Компилятор — по определению это транслятор в машинный код. Если мы считаем байт-код джавовской ВМ машинным кодом, то транслятор джавы — вполне себе компилятор.
Я спросил «нет ли там такого?», а «какого» — пояснил примером другой машины.
У типового IBM терминала только функциональные клавиши и Enter вызывали прерывания — поэтому например игрушка Tetris для EC-7927 использовала четыре клавиши PF для поворота, перемещения и бросания фигур. И способа комбинировать нажатия не было как такового.
Пфф, да понятно что парой строк выше можно смотреть, можно вообще весь код перечитать чтобы понять что в одной строке происходит. Да только вот явное — лучше чем неявное
Не потребуется. Здесь за счет короткого scope'а это будет в пределах взора. Плюс, человек, который «в теме», знает, какие регистры для чего обычно применяются (тот же esi), и у него не возникнет вопросов подобных вашим, а-ля «а что же в eax после вызова GetCRC32 посредством stdcall?»
это позволительно только специфическому языку, но никак не «полезному и удобному»
А Ассемблер — как раз специфический язык. И сам по себе ни фига не удобный, если сравнивать с ЯВУ.
С таким же успехом можно прям в опкодах программировать. Ну а что? Если потом взять таблицу кодов — можно будет легко понимать где что. Удобно и полезно. Почему бы не писать на машинных кодах? Зачем вообще ассемблер, эта ненужная прослойка? Машинные коды — не бог весть какая сложность.
Нет, в случае именно x86 разница как раз колоссальна, вы просто, видимо, не знаете о чем говорите. Даже если мы отложим в сторону то, что мы говорим о макроассемблере, который по функционалу в чем-то близок к Си, пусть ограниченному подмножеству, то основное преимущество использования мнемокода по сравнению с машинным — это расчет адресов.
Можно было вызвать какой-нибудь stdcall GetTemplatedCode, который вернул бы нам строку по шаблону, разница невелика для данного конкретного случая, кмк.
Вы пытаетесь доказать, что писать на асме подобные приложения сложно по сравнению с ЯВУ. Это бесполезная борьба с ветряными мельницами. Говоря об удобстве, имеется в виду, что «все не так плохо, как казалось», не более. ИМХО.
Как может быть понятен код, в котором даже нельзя наименовать переменную так как мне надо (точнее можно, но в том случае если это именно своя переменная а не системный регистр)?
Да элементарно: область видимости сокращается, парой строк выше можно увидеть, что именно задается в esi или какой там регистр использовался. Ну, будет у вас вместо
if(abc* ==…
mov esi, abc
…
cmp [esi],…
И парадигма тут ни при чём. Вот смотрите — как бы там не было, но в моём коде чётко понятно что в $user — очевидно хранятся данные пользователя. И это одна строка кода, урывок из контекста.
Ну так и что-то вроде
mov esi, user
mov eax, [esi+_user.name]
не бог весть какая сложность.
Теперь берём отрывок асма.
bswap eax откуда мне знать что мы храним в eax в данный момент?
Из знания конвенции вызова. Результат работы функции там хранится. Обмен, очевидно, производится из-за разницы endianess.
А почему сравниваем это? Что такое esi и edx? Сравните какое-нибудь
Потому что, очевидно, мы сравниваем полученный нами ЦРЦ с находящимся в буфере. esi — наверняка указатель на буфер, edx — текущий «бегунок», указатель на ЦРЦ в самом буфере. Я не уверен, что это так — cам код не смотрел. Но исходя из отрывка оно так.
И ооп тут ни при чём — изменить user.type (ооп, объект) на user[«type»] (массив, более функциональный подход) — менее понятно не станет.
Нет, простите, при чем. Давайте тогда смоделируем обсуждаемый отрывок:
bool DoComething(char* buf) {
uint CRC;
char* offset;
…
…
CRC = DataCRC32(buf, offset);
SwapHL(&CRC); — тут я просто не знаю, как это в Си делается
if (uint*(buf + offset) == CRC) {
…
…
и будем сравнивать одинаковые парадигмы. Уже разница не так ощутима. А если использовать в FASM макросы if then else, разница станет еще менее заметной.
Он компилируемый и так и так, без приведенных допущений.
Байт код — родной для виртуальной машины JVM. Ваши требования «нативности» — волюнтаризм, к градации «компиляция-не компиляция» не имеют отношения.
Упор на производительность — это демагогия, см. пример с компиляцией и Bochs. Компилируемый язык или нет — не зависит от того, нативный ли код на выходе. Если вы, условно, транслируете программу на платформе Win32 / x86 под Linux/Itanium, то вы выполняете компиляцию, хоть тресни. Кросс-компиляцию, но тем не менее.
Для начала разберитесь в определениях, которые отличаются от ваших хотелок, потом вернемся к разговору.
Технология, которая позволяет экономить время процессора (я имею в виду не сам ЮБ а опцию прямой перегонки между ее узлами) — не показатель того, что экономится время процессра? Ок.
Еще бы — вторая после Крея по производительности на то время. Да, пакетный режим — он такой. Но многотерминальные системы с соответствующей ОС там ведь тоже были…
Не согласен. Если бы это было так, то у этой серии бы не было юнибаса с прямой перегонкой (не только DMA) между устройствами. Да и скромная производительность ЦП не позволяет говорить о том, что этот ресурс не надо экономить.
Читал, что в комплексе БЭСМ-6 (другого класса машина, но не суть) использовались АЦПУ, генерирующие прерывания при печати в соответствии с вращением алфавитного барабана, в котором, по идее, должно быть 64-128 позиций, т.е. 64-128 прерываний за один поворот барабана, который вращается много быстрее, чем 1 об в минуту. Хороший пример «неумного» устройства.
И тем не менее, в DECовских машинах такое чтение было возможным, несмотря на наличие DMA. Это вопрос гибкости. Но припоминаю рассказы старших товарищах о проблемах с реализацией игр как раз из-за терминальной стойки на ЕС.
На СМ-1420, пусть н с 1, но с 2-4 мегабайтами памяти и соответствующим мультиплексором, тоже могли работать 20-30 человек.
Только у посредственностей, которым тяжело дается изучение чего бы то ни было. Для остальных уже изученное — пройденный этап, они уже впереди, ведь они прошли это, поэтому могут делиться.
Замечательно. Значит то, что некий машинный код — интерпретируется, не делает транслятор в этот код не-компилятором?
Тем более это не дает оснований говорить о не-компиляции.
Не додумывайте условий про «заданную платформу». Компилируемость не определяется «конкретной платформой», иначе у нас не было бы кросс-компиляторов.
Нет, это корректное допущение. У нас гипотетически может быть «железный» процессор, работающий с байт-кодом. Если у вас есть виртуальная машина, скажем, bochs или что-то аналогичное, работающее с x86 кодом, который является продуктом компилтора gcc, вы же не будете говорить, что мы имеем дело не с компиляцией, поскольку код исполняется виртуальной машиной.
И что? Машинный код многих процессоров тоже интерпретируется.
Помню свои ощущения, когда впервые вступил в живой разговор с начальником-американцем. До этого общались письменно, общались устно с коллегами-неамериканцами. А тут… такое забавное ощущение, когда человек что-то тебе говорит, говорит, говорит, ты понимаешь все слова по отдельности, а вот фразу — нет. Ни по логике построения, ни просто по скорости. И стоишь так, понимаешь, что он тебя что-то спросил — чисто по интонации. Соображаешь, что же от тебя хотят. Ничего, постепенно втянулся, научился воспринимать native speaker'ов на слух. Но первая встреча с носителем — как удар по голове.
Ясно.
Смысл, если это — не бутылочное горлышко?
Нет, это чистой воды ответ «экономить на спичках — глупо».
Не потребуется. Здесь за счет короткого scope'а это будет в пределах взора. Плюс, человек, который «в теме», знает, какие регистры для чего обычно применяются (тот же esi), и у него не возникнет вопросов подобных вашим, а-ля «а что же в eax после вызова GetCRC32 посредством stdcall?»
А Ассемблер — как раз специфический язык. И сам по себе ни фига не удобный, если сравнивать с ЯВУ.
Нет, в случае именно x86 разница как раз колоссальна, вы просто, видимо, не знаете о чем говорите. Даже если мы отложим в сторону то, что мы говорим о макроассемблере, который по функционалу в чем-то близок к Си, пусть ограниченному подмножеству, то основное преимущество использования мнемокода по сравнению с машинным — это расчет адресов.
Разве я где-то утверждал обратное?
Да элементарно: область видимости сокращается, парой строк выше можно увидеть, что именно задается в esi или какой там регистр использовался. Ну, будет у вас вместо
if(abc* ==…
mov esi, abc
…
cmp [esi],…
Ну так и что-то вроде
mov esi, user
mov eax, [esi+_user.name]
не бог весть какая сложность.
Из знания конвенции вызова. Результат работы функции там хранится. Обмен, очевидно, производится из-за разницы endianess.
Потому что, очевидно, мы сравниваем полученный нами ЦРЦ с находящимся в буфере. esi — наверняка указатель на буфер, edx — текущий «бегунок», указатель на ЦРЦ в самом буфере. Я не уверен, что это так — cам код не смотрел. Но исходя из отрывка оно так.
Нет, простите, при чем. Давайте тогда смоделируем обсуждаемый отрывок:
bool DoComething(char* buf) {
uint CRC;
char* offset;
…
…
CRC = DataCRC32(buf, offset);
SwapHL(&CRC); — тут я просто не знаю, как это в Си делается
if (uint*(buf + offset) == CRC) {
…
…
и будем сравнивать одинаковые парадигмы. Уже разница не так ощутима. А если использовать в FASM макросы if then else, разница станет еще менее заметной.