LINUX.ORG.RU

А как в вашем ЯП относятся к целочисленному переполнению?


0

4

Навеяло недавним забавным багом в Диабло. Вот взять джаву. Вроде современный безопасный язык, память не расстрелять, хоть ты что делай, нулл не разыменовать, все такие баги вылетают с исключениями. Вот с делением на 0 не помню, но вроде тоже исключение вылетит, если не float делишь. А int переполнится и фиг ты об этом узнаешь.

Я встречал очень мало случаев, когда переполнение int-а при арифметической операции было бы корректным выполнением алгоритма. В реальной жизни об этом не думают вообще никогда, ибо 4 млрд это много и хватит каждой домохозяйке. Раз в сто лет не хватает и там вылезает бага. И бага, обычно, пренеприятная. Например как в диабле.

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

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

Или я не знаю возможностей современных аппаратных платформ и это всё есть, просто глупые джавы это не используют?

★★★★★

Чисто мое имхо — процессор должен кидать исключение

ты не тех грибов кушал. Кстати, где ты их в мае нашёл?

А как ваш ЯП помогает

у меня ЯП существует под лозунгом «коси и забивай». Сишечка.

#include <stdio.h>
int main (void) {
	unsigned a = 4000000000;
	unsigned b = a+a;
    printf ("%u + %u == %u\n", a, a, b);
    return 0;
}
0000000000400628 <main>:
  400628:	55                   	push   rbp
  400629:	48 89 e5             	mov    rbp,rsp
  40062c:	48 83 ec 10          	sub    rsp,0x10
  400630:	c7 45 fc 00 28 6b ee 	mov    DWORD PTR [rbp-0x4],0xee6b2800
  400637:	8b 45 fc             	mov    eax,DWORD PTR [rbp-0x4]
  40063a:	01 c0                	add    eax,eax
  40063c:	89 45 f8             	mov    DWORD PTR [rbp-0x8],eax
  40063f:	8b 4d f8             	mov    ecx,DWORD PTR [rbp-0x8]
  400642:	8b 55 fc             	mov    edx,DWORD PTR [rbp-0x4]
  400645:	8b 45 fc             	mov    eax,DWORD PTR [rbp-0x4]
  400648:	89 c6                	mov    esi,eax
  40064a:	bf 4c 07 40 00       	mov    edi,0x40074c
  40064f:	b8 00 00 00 00       	mov    eax,0x0
  400654:	e8 57 fe ff ff       	call   4004b0 <printf@plt>
  400659:	b8 00 00 00 00       	mov    eax,0x0
  40065e:	c9                   	leave  
  40065f:	c3                   	ret    
drBatty ★★
()
Ответ на: комментарий от Napilnik

«Иногда лучше жевать, чем говорить»(ц)

>>> 2**32*2**32
18446744073709551616L
>>> 2**32*2**32+1
18446744073709551617L
>>> 1<<64
18446744073709551616L
Просто в питоне есть длинные целые;-)

PS

>>> hex(18446744073709551616)
'0x10000000000000000L'
>>> hex(18446744073709551617)
'0x10000000000000001L'
А то щас выясниться, что Ъ-кодеры не в курсах скока будет 2 в 64-й степени.

AIv ★★★★★
()
Последнее исправление: AIv (всего исправлений: 1)
Ответ на: комментарий от drBatty

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

anonymous
()
Ответ на: комментарий от AIv

Просто в питоне есть длинные целые;-)

Длинные целые уже не int а другой целочисленный тип и он тоже не бесконечный.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

В питоне при переполнении (в рез-те арифметических действий над обычными целыми int32_t) генерируется длинное целое. И в питоне длинные целые таки бесконечные (ну ограничены типа объемом RAM).

Хватит уже позориться.

AIv ★★★★★
()
Ответ на: комментарий от AIv

В питоне при переполнении (в рез-те арифметических действий над обычными целыми int32_t) генерируется длинное целое. И в питоне длинные целые таки бесконечные (ну ограничены типа объемом RAM).

Хватит уже позориться.

Да вот ты позоришь питон: и так склонность питоновых программ к сокрытию багов была известна а ты её только что подтвердил. Если в языке со строгой типизацией я перепутаю данные и в результате в переменную типа BYTE попадёт число выходящее за диапазон 0..255, то при выполнении очень скоро узнаю в каком месте накосячил. А в случае с питоном оно будет тихо мирно глючить и скрывать симптомы.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Ничего, что питон ЯП с утиной типизацией и предназначен для решения немножко других задач?

А ты слил вчистую, три сообщения подряд пытаясь понять вообще о чем речь идет, принимая сначала long за float, а потом рассуждая о типах. А теперь еще жалко оправдываешься, питон тебе не гож...

AIv ★★★★★
()
Ответ на: комментарий от AIv

Ничего, что питон ЯП с утиной типизацией и предназначен для решения немножко других задач?

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

А ты слил вчистую, три сообщения подряд пытаясь понять вообще о чем речь идет

Не маскируй свой слив за невнятностью своих сообщений.

принимая сначала long за float, а потом рассуждая о типах.

Только для скриптовика все типы на одно лицо, так что не гони. К тому же не спрашиваю откуда ты высосал именно long и float чем продемонстрировал собственную безграмотность.

А теперь еще жалко оправдываешься, питон тебе не гож...

Да нет, веселюсь тортовости твоих наездов.

Napilnik ★★★★★
()
Ответ на: комментарий от Legioner

Очень медленно.

А ну да, 2-3лишних инструкции беспокоят жабиста - очень медленно. Люди, вы такие смишные.

Ну и заодно отвечу на все твои вопросы:

Я встречал очень мало случаев, когда переполнение int-а при арифметической операции было бы корректным выполнением алгоритма. В реальной жизни об этом не думают вообще никогда, ибо 4 млрд это много и хватит каждой домохозяйке. Раз в сто лет не хватает и там вылезает бага. И бага, обычно, пренеприятная. Например как в диабле.

Дак не юзай инт, не? Все проблемы не из-за переполнения инта( переполняют инт только глупые люди), а из-за неосиляторства, представляешь, но ~80% программистов не понимают, что такое unsigned, типы вообще, либо типы кроме инта, чара и флоата/дубла и т.п. А ну да, это ЯП плохое, не безопасное.

Почему так - ты поймёшь в соседнем треде. А ну да, если указатель не кастится в инт - это проблема не дурачка, а инта, ибо в него должно влазить всё, а типы вообще не безопасны и ошибки невольны.

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

Реалезуй это в рантайме, почему-то к действительно тормазящим вещам у вас отношение пофигистическое «такты считают лохи», а до a+b дописать что-то типа ((MAX-A) < b ), если уж полный дурачек, либо считать в uint64_t, если похож на человека, что будет быстрее любого твоего софтварного исключения, но нет же - ему надо «аппаратную реализацию», чтобы запилить на ней иключение. От как круто мы живём.

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

А как помогает тебе стена, когда происходит непредвиденное столкновение? Правильно, тебе стена учит не биться об неё, так и тут, а мягнкие стены делают, я думаю, знаешь для кого.

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

superhackkiller1997
()
Ответ на: комментарий от unt1tled

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

Никаких шансов у лиспашины против даже х86 нет, а если и есть это где-то уровень среднестатистического жаба-интерпрайза - т.е. 5-10% производительности х86 в среднем. Да, перегнать их - это прогресс, и авось когда-то, потратя миллионы человекалет( в трубу) этот прогресс (не) произойдёт.

Лисп не менее обезъяночный язык, «паскалеподобный»( мне похрен какое подобие у него реально) и избыточно-примитивный синтаксис говорит об этом больше, чем что-то другое. Его сложность миф, ибо под ним нет ничего, особенно у лисп машины. А любое программирование без учитывания особенность таргета - есть обезъяничество по определению.

Они умерли, а почемуже? Лиспец не ложится на сегодняшную архитектуру - бидняжка, ему нужна своя - как пичально. А своя архитектура не работает даже на уровне галимого х86 - в двойне бедняшка. И почему же они умерли - да, неосиляторство.

Очередной Торвальдс пусть изобретёт максимальное упращённую архитектуру, которую не осилит неосилятор и которая не будет ограничивать своим прогибанием под неосиляторов осиляторов. Сделает из ущербной сишки более-менее вменяемый язык( выкинув оттуда ущербности бородатых годов, которые тащат из стандарта в стандарт), упростив его, перепесав на этом языке компелятор нормально + минимальное описание к нему и дать в руки каждому зелёному - тогда мир программистов преобразится во что-то более-менее нормальное, а не 99% пхп-обезъянок, как сейчас.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

А ну да, 2-3лишних инструкции беспокоят жабиста - очень медленно. Люди, вы такие смишные.

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

Я встречал очень мало случаев, когда переполнение int-а при арифметической операции было бы корректным выполнением алгоритма. В реальной жизни об этом не думают вообще никогда, ибо 4 млрд это много и хватит каждой домохозяйке. Раз в сто лет не хватает и там вылезает бага. И бага, обычно, пренеприятная. Например как в диабле.

Дак не юзай инт, не? Все проблемы не из-за переполнения инта( переполняют инт только глупые люди), а из-за неосиляторства, представляешь, но ~80% программистов не понимают, что такое unsigned, типы вообще, либо типы кроме инта, чара и флоата/дубла и т.п. А ну да, это ЯП плохое, не безопасное.

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

Почему так - ты поймёшь в соседнем треде. А ну да, если указатель не кастится в инт - это проблема не дурачка, а инта, ибо в него должно влазить всё, а типы вообще не безопасны и ошибки невольны.

При чем здесь указатель вообще?

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

Реалезуй это в рантайме, почему-то к действительно тормазящим вещам у вас отношение пофигистическое «такты считают лохи», а до a+b дописать что-то типа ((MAX-A) < b ), если уж полный дурачек, либо считать в uint64_t, если похож на человека, что будет быстрее любого твоего софтварного исключения, но нет же - ему надо «аппаратную реализацию», чтобы запилить на ней иключение. От как круто мы живём.

В рантайме это невозможно реализовать без сильного ухудшения производительности. Если нет аппаратной поддержки в процессоре. Для джавы и си это неприемлемо. И речь не о счете тактов.

uint64_t переполняется так же легко, как и int.

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

А как помогает тебе стена, когда происходит непредвиденное столкновение? Правильно, тебе стена учит не биться об неё, так и тут, а мягнкие стены делают, я думаю, знаешь для кого.

Я рад, что у тебя такие познания в области мягких стен, чувствуется опыт. Но в треде речь немного не об этом.

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

И про копрофильские фантазии — в другое место, пожалуйста. Но аналогия верная, хороший ЯП высокого уровня должен отлавливать или не допускать максимальное число ошибок программиста.

Legioner ★★★★★
() автор топика
Ответ на: комментарий от Napilnik

К тому же не спрашиваю откуда ты высосал именно long и float чем продемонстрировал собственную безграмотность.

Вот отсюда, деточка: А как в вашем ЯП относятся к целочисленному переполнению? (комментарий)

Дохрена + 1 = дохрена. На баг похоже или число с плавающей запятой но никак не на int.
Napilnik **** (11.05.2013 5:10:06) 

Что бы принять

>>> 2**32*2**32
18446744073709551616L
за баг или за число с плавающей запятой надо быть совершенно в ноль упоротым созданием, что впрочем и по остальным твоим комментам видно.

AIv ★★★★★
()
Ответ на: комментарий от Legioner

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

Реально? В 2-3раза? Осиль матчасть, это будет последнее, что будет тормазить в твоей жаве - поверь мне. Каждый твой объект - лишнии 2-3инструкции, твоя ГЦ - лишнии десятки инструкций, если не сотни. И тут тебя, жабиста пробило на

И да, напиши бенчмарк - удивишься. Никаких 2-3раза эта проверка тебе не даст.

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

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

При чем здесь указатель вообще?

Почему для людей «переполнение» - это проблема, да потому, что они не осиляторы, как и те, кто кастит указатель в инт, чтобы сложить его со счётчиком, как в соседнем треде. Это пример.

В рантайме это невозможно реализовать без сильного ухудшения производительности. Если нет аппаратной поддержки в процессоре. Для джавы и си это неприемлемо. И речь не о счете тактов.

В рантайме без сильного ухудшения производительности НЕЛЬЗЯ СДЕЛАТЬ 90% фич твоей живы, начиная от самой концепции вм, заканчивая гц, объектами и исключениями. Как жешь ты с этим жил? А тут вдруг бам и у тебя будет тормазить?

Я не видел твоих постов про ВМ, ГЦ, Объекты, где они? Нету, а вот про переполнение у тебя есть - налицо балабольство чистой воды.

uint64_t переполняется так же легко, как и int.

Реально? Смотри ответ выше, и научись думать. Там написанно СЧИТАТЬ, вот считай, тогда это будет стоить одной инструкции, а не 3.

Я рад, что у тебя такие познания в области мягких стен, чувствуется опыт. Но в треде речь немного не об этом.

Тред об этом. Дак ты не ответил на вопрос, что надо сделать со стенами, чтобы небыло непредвиденнных столкновений? И как в этом помогают тебе твои стены?.

И про копрофильские фантазии — в другое место, пожалуйста. Но аналогия верная, хороший ЯП высокого уровня должен отлавливать или не допускать максимальное число ошибок программиста.

А может быть свои ошибки ты будешь отлавливать сам? Ах, какая жизнь плохая, не отлавливает твои ошибки, да? Бедняжка, что же делать?

И да, как мы уже выясняли проблемы «тормазов» - это твой блеф во имя сокрытия неосиляторства. Эта проверка не даст замедления вообще и это замдление будет последним, что почувствуешь у жабы.

Берёшь Сишку, и реализуешь своий инкремент с чекером и сравниваешь с обычным инкриментом, а потом начинаешь говорить о тормазах. Если там будет действительно 200%, то я признаю тебя.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Да, перегнать их - это прогресс

Процессоры клепать очень просто. В нормальных институтах (типа MIT) студенты в конце семестра сдают RISC-like микропроцессор, а выпускик и суперпайплайновый, суперскалярный, с кэшем и бранч-предиктором сдаёт. Где-то в паре километров от моего дома есть контора со штатом 5 человек, которая клепает мультипроцессор в кремнии для коммерческого пользования, забыл уж чего он там так хорошо делает.

Лисп не менее обезъяночный язык, «паскалеподобный»( мне похрен какое подобие у него реально) и избыточно-примитивный синтаксис говорит об этом больше, чем что-то другое. Его сложность миф, ибо под ним нет ничего, особенно у лисп машины. А любое программирование без учитывания особенность таргета - есть обезъяничество по определению.

Ты сейчас занимаешься обсиранием стихов Пушкина, не умея даже толком этим стихи читать.

Они умерли, а почемуже? Лиспец не ложится на сегодняшную архитектуру - бидняжка, ему нужна своя - как пичально. А своя архитектура не работает даже на уровне галимого х86 - в двойне бедняшка. И почему же они умерли - да, неосиляторство.

На сегодняшнюю архитектуру ложится всё. И так хорошо ложится, что потребность в специализированном железе отпала. Можно провести аналогию с машинами: современный семейный пепелац легко разгоняется до 200 км/ч, что всего 50 лет назад было уделом специализированных спорт-каров. И то, 200 км/ч - это электроникой ограниченно, а так ещё быстрее переть может.

mv ★★★★★
()
Ответ на: комментарий от mv

Процессоры клепать очень просто. В нормальных институтах (типа MIT) студенты в конце семестра сдают RISC-like микропроцессор, а выпускик и суперпайплайновый, суперскалярный, с кэшем и бранч-предиктором сдаёт. Где-то в паре километров от моего дома есть контора со штатом 5 человек, которая клепает мультипроцессор в кремнии для коммерческого пользования, забыл уж чего он там так хорошо делает.

А никто не говорит, что склепать вменяемый процессор сложно, особенно с приходом говняканье на обехъяних недоязыках, жаль, что тот тред удалили.

Ты сейчас занимаешься обсиранием стихов Пушкина, не умея даже толком этим стихи читать.

Меня мнение СПГсников по поводу стихов пушкина не интересует, единственное их опрадвание - это «я не понимаю», а что я не понимаю они объяснить мне не могут, как и сам смысл 95% стихов. А так, обсираю.

На сегодняшнюю архитектуру ложится всё. И так хорошо ложится, что потребность в специализированном железе отпала. Можно провести аналогию с машинами: современный семейный пепелац легко разгоняется до 200 км/ч, что всего 50 лет назад было уделом специализированных спорт-каров. И то, 200 км/ч - это электроникой ограниченно, а так ещё быстрее переть может.

Отпала она не потому, отпала она из-за обезъянок, как сказал чиловек, на коммент которого я ответил.

Как я люблю ваши аналогии, они просто ласкуют мой слух. Сегодня любая жаба-какаха обрабатывает терабайты данных, а раньше это был удел только узкоспециализированных обрабатывалок. А то, что есть такая штука как разгон и время на 1тб, которые не улучшились, а максимум приблизились к технологиями 20летней давности, то тебя не волнует.

А разве не ущербностью конструкции и ДВС? Електроникой, ага.

superhackkiller1997
()
Ответ на: комментарий от cdshines

это какой специальности, погромисты или инженеры? Или там не делают различий?

Железячники.

mv ★★★★★
()
Ответ на: комментарий от superhackkiller1997

Всё, что я пока тут вижу - это дёрганье одной-единственной обезъяны, которой я сейчас отвечаю.

mv ★★★★★
()
Ответ на: комментарий от mv

Судя по твоим аналогиям и черезстрочным ответам - не очень-то и успешно. А так да, дёрганье.

superhackkiller1997
()
Ответ на: комментарий от mv

Процессоры клепать очень просто.

Так толсто, что даже тонко %)

tailgunner ★★★★★
()
Ответ на: комментарий от AIv

А они их в кремнии сдают или тока документацию?

FPGA.

Что показательно, первую лисп-машину (MIT CONS) сделал Гай Ричи в качестве проекта по окончанию 6-недельного или около того курса по VLSI. Проц был в кремнии, на одном кристалле рядом с кучей проектов других студентов.

mv ★★★★★
()
Ответ на: комментарий от mv

Интересно. Про это есть что почитать? Кто изготавливает студенческие поделки? Это же фактически штучная партия на фоне масштабов tsmc, например.

cdshines ★★★★★
()
Ответ на: комментарий от tailgunner

Ну так разорви замкнутый круг - не дави на эмоции,

Почему бы тебе первому не начать, не прояснить чем по-твоему (или дать ссылку на первоисточник, если это не твоё мнение) лисп-машины менее универсальны, чем любые другие.

объясни, как «сегменты в защищиенном режиме» заменяют теги.

Я нигде не утверждал, что они их заменяют, или являются аналогами, или служат для той же цели. У сегментов в защищённом режиме есть атрибуты. Это другая, более примитивная и служащая другим целям реализация идеи, что данные нужно как-то помечать, что это за данные, кому принадлежат и зачем нужны.

auto12884839
()
Ответ на: комментарий от anonymous

Может Гай Стил, а то и Том Найт? Гай Ричи это же известный режиссер.

Йеп, Гай Дж. Стил, ошибочка вышла. Прочитать можно, по-моему, в Coders at work. Или это тезис про сам MIT CONS был?..

mv ★★★★★
()
Ответ на: комментарий от cdshines

Интересно. Про это есть что почитать? Кто изготавливает студенческие поделки? Это же фактически штучная партия на фоне масштабов tsmc, например.

Это было 40 лет назад. Сейчас про кремний не знаю. Маловероятно, ведь теперь есть FPGA.

mv ★★★★★
()
Ответ на: комментарий от superhackkiller1997

Как я люблю ваши аналогии, они просто ласкуют мой слух. Сегодня любая жаба-какаха обрабатывает терабайты данных, а раньше это был удел только узкоспециализированных обрабатывалок. А то, что есть такая штука как разгон и время на 1тб, которые не улучшились, а максимум приблизились к технологиями 20летней давности, то тебя не волнует.

ты таки матчасть подучи, ладно? Кофемолка какой была, такой и осталось. Просто раньше там байтики считать надо, а сегодня не нужно, любая IT-овечка с лёгкостью забьёт Over9000 рецептов на .NET, и повесит на одну кнопку.

А разве не ущербностью конструкции и ДВС? Електроникой, ага.

ДВС на сегодня почти совершенный. Лучше не будет.

drBatty ★★
()
Ответ на: комментарий от mv

Что показательно, первую лисп-машину (MIT CONS)

там не очень и сложно, на самом-то деле. Возни много, да.

Это было 40 лет назад. Сейчас про кремний не знаю. Маловероятно, ведь теперь есть FPGA.

FPGA давно уже существуют. Их ещё в СССР делали вполне себе массово. (правда маленькие, на CPU наверное не хватило-бы, но это в совке)

drBatty ★★
()
Ответ на: комментарий от drBatty

ты таки матчасть подучи, ладно? Кофемолка какой была, такой и осталось. Просто раньше там байтики считать надо, а сегодня не нужно, любая IT-овечка с лёгкостью забьёт Over9000 рецептов на .NET, и повесит на одну кнопку.

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

ДВС на сегодня почти совершенный. Лучше не будет.

Ну когда ты научишься читать, ты видишь, что там есть 'и'? Ущербность не двс, а ущербность конструкции автомобиля, и ДВС сам как образец ущербности. И уж до совершенства ему как до луны пешком.

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

superhackkiller1997
()
Ответ на: комментарий от anonymous

Молодец, почти. Сишка не инструмент, а материал. Очень многие пытаются опрадаться теорией об инструментах, типа «жава для деревенского интерпрайза», «пхп для веба», «сишка для дров и ОС», «лисп какбэ для всего, но это чисто теоретически, а на самом деле он ниначто не годится из-за того, что все его не осилили» и т.п.

Но их теория рушится на сиасме, у которого физически нет ограничений на софтварном уровне. Если у всех других популярных ЯП ограничения есть, то тут нет, да неосиляторы пытаются придумать оправдания, аля «слишком долго пилить( кому? никаких испытаний не проводилось, пруфов нет - сплошное балабольство)», она не безопасна( почти весь самый надёжный код написан на сиасем и систайл плюсах, что какбэ делит на ноль их умозаключение, но логика не их конёк" и т.п.

Даже следуя теории инструментов у сишки нет специализации, она не подходит под описание инструмента по всем канонам.

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

Как-то так.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

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

а по твоему не прогресс? Обе домохозяйки (и та, что код пишет, и та, что кофеварку купила) — довольны. Что ещё надо-то? 100ms это «мгновенно», в буквальном смысле слова.

Или в твоей альтернативной реальности (каюсь, я в ней некомпетентен, ты такие перлы тут выдавал, я ажно чуть не описался кипятком), всё это тоже как-то иначе, не так, как оно у нас? Кофеварки другие что-ли? Или домохозяйки вбивают гуй в свои 8Кбайт EPROM, которые в нашей реальности были в 80х годах прошлого века?

Ну когда ты научишься читать, ты видишь, что там есть 'и'? Ущербность не двс, а ущербность конструкции автомобиля, и ДВС сам как образец ущербности. И уж до совершенства ему как до луны пешком.

Смешно почитать рассказки такого ГСМ, как ты. Ты хоть примерно представляешь, сколько миллиардов баксов вбито в конструкцию этого ДВС? Да будь он даже-бы действительно такой ущербный by design, это никого не волнует. Других у нас тупо нету. И судя по всему — не будет, пока нефть не кончится.

drBatty ★★
()
Ответ на: комментарий от superhackkiller1997

Сишка не инструмент, а материал.

Сегодня у тебя на столе какие-то совсем особые грибы…

Но их теория рушится на сиасме, у которого физически нет ограничений на софтварном уровне. Если у всех других популярных ЯП ограничения есть, то тут нет

ты не в теме. Про Тьюринга слышал? Писать что угодно можно на любом Тьюриг-полном ЯП. Хоть на brainfuck'е. Стыдно не знать таких азов.

Если у всех других популярных ЯП ограничения есть, то тут нет, да неосиляторы пытаются придумать оправдания, аля «слишком долго пилить( кому? никаких испытаний не проводилось, пруфов нет - сплошное балабольство)»

Пруф хочешь? Ну напиши мне реализацию скажем сбалансированного дерева на своём сиасме.

она не безопасна( почти весь самый надёжный код написан на сиасем и систайл плюсах, что какбэ делит на ноль их умозаключение, но логика не их конёк" и т.п.

с т.з. логики делить на ноль нельзя. А ЯП — просто инструмент. Отвёртка тоже опасна, если ей в ухе ковырять. Сишечка сама по себе более опасна просто лишь потому, что там нет, не было, и нет никаких заборчиков, костылей, и страховочных верёвочек, коих полно в других ЯП (вроде того, что предложил ввести ТС). Как я уже говорил — сишечка ЯП для пох**ов, всем по. В Стандарте на все 7 бед — UB ответ. Это даёт компилятору свободу для манёвра, что-бы засунуть данный код в _любую_ архитектуру. Но за всё надо платить, ибо кривой быдлокод никто проверять не станет, он просто тупо возьмёт и выполнится AS IS. Как например переполнение int или деление на ноль. Сишечке глубо ко нас рать, она просто возьмёт и скомпилирует. А процессор будет переполнять свой int и делить на ноль, как указал Великий Программист.

drBatty ★★
()
Ответ на: комментарий от drBatty

а по твоему не прогресс? Обе домохозяйки (и та, что код пишет, и та, что кофеварку купила) — довольны. Что ещё надо-то? 100ms это «мгновенно», в буквальном смысле слова.

А ну да, меня одалевает даже 20-30мс задержки на появление символов при вводе, а тут 100мс для него «мгновенно» - поверю на слово.

Причем тут домохозяйки и почему они довольны мы никогда не поймём.

Или в твоей альтернативной реальности (каюсь, я в ней некомпетентен, ты такие перлы тут выдавал, я ажно чуть не описался кипятком), всё это тоже как-то иначе, не так, как оно у нас? Кофеварки другие что-ли? Или домохозяйки вбивают гуй в свои 8Кбайт EPROM, которые в нашей реальности были в 80х годах прошлого века?

Это уже раз 3-4-й, когда ты начинаешь со мной спорить, потом сливаешься и благополучно забываешь разговор. На фоне этого твои разговоры про «перлы» выглядят так нелепо, что просто смишно.

Причем тут домохозяйки и почему они довольны мы никогда не поймём.

Смешно почитать рассказки такого ГСМ, как ты. Ты хоть примерно представляешь, сколько миллиардов баксов вбито в конструкцию этого ДВС? Да будь он даже-бы действительно такой ущербный by design, это никого не волнует. Других у нас тупо нету. И судя по всему — не будет, пока нефть не кончится.

Т.е. ты со своего фейла съюлил на баквы, ок. Представляешь сколько миллиардов баксов слито на жабу? Да будь он даже-бы действительно такой ущербный будизайн - это никого не волнует.

Просто сишно, суть не в том, что почему-то ДВС не выпилили, а суть в том, что комментатор сморозил фигню, как и ты. А ну да, да. То-то я гляжу поезда ездя, «паравозы» тянут, краны строят - да, ничего нету.

Естественно на рынке хомячков никогда ничего не будет в доступном сегменте, но найти ты можешь и сейчас. Да и дело не в этом, а как я уже сказал в вашем эпичном скилле анологистов.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

А ну да, меня одалевает даже 20-30мс задержки на появление символов при вводе, а тут 100мс для него «мгновенно» - поверю на слово.

100ms это задержка гуя на кнопку ОК. А символы домохозяйки локально вводят, в самом тулките например.

Причем тут домохозяйки и почему они довольны мы никогда не поймём.

их это всё устраивает. Что непонятного?

Это уже раз 3-4-й, когда ты начинаешь со мной спорить, потом сливаешься и благополучно забываешь разговор. На фоне этого твои разговоры про «перлы» выглядят так нелепо, что просто смишно.

я ничего не забываю. Просто ты начинаешь с анонимусами ругаться, и ваши высокоинтеллектуальные разбирательства про ваших мамочек успешно трутся модераторами. Смысл мне туда лезть? Не имею чести быть знакомыми с вашими мамами.

Представляешь сколько миллиардов баксов слито на жабу?

копейки, против ДВС.

Просто сишно, суть не в том, что почему-то ДВС не выпилили, а суть в том, что комментатор сморозил фигню, как и ты. А ну да, да. То-то я гляжу поезда ездя, «паравозы» тянут, краны строят - да, ничего нету.

«паровозы» жрут либо нефть через ТЭС, либо сами жрут мазут своим ДВСом, который крутит генератор. Такая же ерунда в экскаваторе, который тоже типа «электрический».

drBatty ★★
()
Ответ на: комментарий от auto12884839

Ну так разорви замкнутый круг - не дави на эмоции,

Почему бы тебе первому не начать

Потому что я оперирую фактами, а не ною, что оппонент ведет «черную риторику».

объясни, как «сегменты в защищиенном режиме» заменяют теги.

Я нигде не утверждал, что они их заменяют, или являются аналогами, или служат для той же цели

Да неужели?

auto12884839> Вместо тегов сейчас сегменты в защищённом режиме

Это именно утверждение о том, что «заменяют, или являются аналогами, или служат для той же цели».

У сегментов в защищённом режиме есть атрибуты

И у страниц есть атрибуты. Страницы тоже вместо тегов?

данные нужно как-то помечать, что это за данные, кому принадлежат и зачем нужны.

Идея о том, что «данные надо помечать» - это далеко не тегированная архитектура.

tailgunner ★★★★★
()
Ответ на: комментарий от auto12884839

сейчас сегменты в защищённом режиме

Auto, в x86-64 cs/ds/es жестко установлены в 0. А в x86 их ставят в 0, лимит в 4 гига и пользуются страничной адресацией.

Так что когда это «сейчас» не ясно.

Я не знаю ничего про лисп машины, но какие нафиг сегменты в современном мире?

onanij
()
Ответ на: комментарий от onanij

Auto, в x86-64 cs/ds/es жестко установлены в 0. А в x86 их ставят в 0, лимит в 4 гига и пользуются страничной адресацией.

Ты всё напутал. Я про атрибуты сегментов говорил.

auto12884839
()
Ответ на: комментарий от tailgunner

Потому что я оперирую фактами, а не ною, что оппонент ведет «черную риторику».

Пока ни одного «факта» о том, что лисп-машины менее универсальны чем любые другие, не поступало.

Это именно утверждение о том, что «заменяют, или являются аналогами, или служат для той же цели».

Нет. Это утверждение о том, что данные теперь имеют атрибуты, в отличие от сплошного адресного пространства режима 8086.

И у страниц есть атрибуты. Страницы тоже вместо тегов?

Почему бы и нет? Более низкоуровневые только.

Идея о том, что «данные надо помечать» - это далеко не тегированная архитектура.

Можно назвать зародышем тегированной архитектуры. В тегированной архитектуре эта идея просто доведена до логического завершения. Ты так и не прояснил, чем полноценное и всестороннее применение меток данных делает архитектуру менее универсальной.

auto12884839
()
Ответ на: комментарий от auto12884839

Пока ни одного «факта» о том, что лисп-машины менее универсальны чем любые другие, не поступало.

Пока ни одного подтверждения озвучиенного тобой «факта» о том, что лисп-машины менее универсальны чем любые другие, не поступало.

auto12884839
()
Ответ на: комментарий от auto12884839

Пока ни одного «факта» о том, что лисп-машины менее универсальны чем любые другие, не поступало.

Почему я должен опровергать это? Напомни, где я это утверждал.

данные теперь имеют атрибуты, в отличие от сплошного адресного пространства режима 8086.

Аафигеть... причем тут вообще 8086? Страничные атрибуты появились задолго до него.

И у страниц есть атрибуты. Страницы тоже вместо тегов?

Почему бы и нет? Более низкоуровневые только.

Ыыы... ты хоть понимаешь, в чем суть тегированной архитектуры? В том, чтобы помечать слова памяти _типами_ данных, которые в них хранятся. Страничные (и сегментные) атрибуты для этого непригодны и не предназначены.

Идея о том, что «данные надо помечать» - это далеко не тегированная архитектура.

Можно назвать зародышем тегированной архитектуры.

Еще один Шалтай-Болтай: «Когда я выбираю слово, оно знаит только то, что я хочу, не больше и не меньше» (ц)

tailgunner ★★★★★
()
Ответ на: комментарий от onanij

Какая разница, если в современных компьютерах (x86 based) сегментация не используется?

Большая. Я про это и говорю, что перестали использовать линейное адресное пространство и в некотором примитивном варианте возобновили то, что было в лисп-машинах в полном масштабе.

auto12884839
()
Ответ на: комментарий от tailgunner

Почему я должен опровергать это?

Нипочему. Ты преподал это как «факт», но ни одного подтверждения этого якобы «факта» пока не поступало. Когда я попросил это обосновать, в ход пошли кривлянья, ужимки и прочий цирк.

Напомни, где я это утверждал.

Я тебя отквотил в одном из своих предыдущих сообщений.

Ыыы... ты хоть понимаешь, в чем суть тегированной архитектуры? В том, чтобы помечать слова памяти _типами_ данных, которые в них хранятся. Страничные (и сегментные) атрибуты для этого непригодны и не предназначены.

Я нигде не утверждал, что они их заменяют, или являются аналогами, или служат для той же цели.

Еще один Шалтай-Болтай: «Когда я выбираю слово, оно знаит только то, что я хочу, не больше и не меньше» (ц)

Ещё один Дзен.

auto12884839
()
Ответ на: комментарий от auto12884839

А зачем оно нужно? Как тебе сказали, теги - это не атрибуты, это некие идентификаторы типа. Атрибуты - это всякие права + ещё я не помню что, но не метка типа

onanij
()
Ответ на: комментарий от auto12884839

Ты лжешь.

Ещё один «факт», подтверждения которому никто никогда не видел.

Не. Фактом без подтверждения было бы «Ты наркоман».

tailgunner ★★★★★
()
Ответ на: комментарий от onanij

А зачем оно нужно? Как тебе сказали, теги - это не атрибуты, это некие идентификаторы типа. Атрибуты - это всякие права + ещё я не помню что, но не метка типа

В контексте обсуждения эти детали неважны. Главное, что я подчеркнул, что с развитием технологий и удешевлением производства начинают встраивать фичи, «ненужные» архитектурам, вытеснившим лисп-машины, а именно некоторые значения, характеризующие хранящиеся данные. И скорее всего, лет через 5-10 персоналки начнут оборудоваться и аппаратным сборщиком мусора, и полноценными тегами. Сейчас этим всем занимается программная часть, так дешевле для неразвитой технологии, а не «менее универсально», как пытается преподнести тот товарищ.

auto12884839
()
Ответ на: комментарий от tailgunner

Не. Фактом без подтверждения было бы «Ты наркоман».

Неочевидно, но боюсь спрашивать обоснования. Цирку, который обычно следует в такой ситуации, сильно не хватает изящества.

auto12884839
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.