ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     11 Mar 2002  19:38:11
 To : "Timur I.Danyarhojaev"
 Subject : Re: Writing a driver programme
 -------------------------------------------------------------------------------- 
 

 sk.ru> <m34rjnqs8a.fsf@vb.dn.ua> <3C8CA86E.FA13FB89@podolsk.ru>
 
 From: Vladimir Bormotov <bor@vb.dn.ua>
    Hi, Timur!
 
 >>>>> "TID" == Timur I Danyarhojaev <tid@podolsk.ru> writes:
 
 >>  TID> А может все гораздо проще?  Есть такой термин Run Time Enviroment,
 >>  TID> у С он HУЛЕВОЙ, в отличии (IMHO) от C++ (как минимум malloc/free).
 >>
 >>  и? что, сейчас в ядре память руками выделяют? Или таки есть некая
 >>  "обертка", которая и состовляет тот самый RunTime Env, причем эта
 >>  обертка написана не программером которые писал компилятор, а
 >>  прикладником (системщиком, если будет так угодно, не в термине дело),
 >>  который хорошо знает свою область, и познания в кодогенерации у него
 >>  явно меньше...
 
  TID> Вот именно руками и выделяют, не используя даже stdio от C.  
  
  тогда я вообще удивляюсь как оно работает. И вспоминаю анекдот про
  дятла...
  
  TID> А в случае с C++, генерировать обращения к RunTime Env будет
  TID> компилятор, А оно само зависит от системы программирования,
  TID> операционной среды (получается Мюнхаузен на лошади в болоте
  TID> пытающийся вытащить сам себя за косицу ;-) ).  
  
  что-то мне кажется что вот это можно легко опровергнуть, но рыться внутри
  gcc я не буду. Hе интересно мне.
  
  Как начны писать свою операционку на C++, тогда пороюсь ;)
  
  TID> Конечно можно для каждой архитектуры хакнуть стандартный компилятор и
  TID> превратить его в ядровой ;-) Hикто не мешает - но к чему?
 
  а к чему на отдельный класс задач пишут отдельный язык? Видимо для
  достижения эжфективности. Hет, не выполнения программы, а труда
  программера.
  
 >>  Кроме того, лично я готов на некоторый оверхед, в замен на то, что у меня
 >>  ядро не будет валиться с Oops, или уходить в трешинг.
 >>
 >>  Может я жуе подсел на Eiffel? не знаю, но чертовски приятно, когда
 >>  backtrace тебе делает сама программа, причем не просто имена функций, а
 >>  еще и значения переменных которые этим функция передавали, и так далее и
 >>  тому подобное.
 
  TID> Лечить проблемы железа программными способами вредно - проверено
  TID> историей развития выч.техники.  
  
  где я говорил что-то про железо?
  Я привел пример того, что если программа написаная на C, падает в корку, и 
  тебе, как разработчику нужно выяснить и полечить, то ты что делаешь?
  Правильно. А я, как програмер пользующий eiffel, спросто смотрю на то, как 
  она падает. Все остальное сделали разработчики eiffel.
  
  Т.е. логика очень проста - если программа таки упала, то есть смысл
  максимально рассказать это сразу, потому что она сама о себе в момент
  падения может рассказать не меньше (на счет больше не уверен) , чем gdb
  по корке. По крайней мере, это гораздо удобнее.
  
  TID> Железо сначала поменять надо, что бы само например различало типы
  TID> данных (как в Эльбрусе-1,2 или еще лучше).  А потом для этого нового
  TID> железа придумать язык адекватный ему.  
  
  1. железо мы можем выбирать в некоторых пределах.
  2. работать нужно на том, что есть
  
  вот я и говорю, что я СОГЛАСЕH на некоторый оверхед, даже на уровне ядра,
  если оно, мне за это сможет говорить, где у меня проблемы с железом.
  
  TID> С адекватен современным архитектурам и может рассматриваться как
  TID> архитектурно-независимый ассемблер.  С++ для современных архитектур
  TID> таким свойством не обладает - требует программной поддержки своих
  TID> конструкций.
 
  независимый асемблер - это ANSI C. Да, сейчас С++ сам генерит целевой код, 
  но насколько я знаю, это не принципиально.
 
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор