Много клиентов с картами - Page 2

Hello, Dima!
You wrote to Alexander Derazhne on Mon, 13 Sep 2004 18:00:00 +0400:

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

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

 >>  Примеры есть и работают, но они являются частью большей
 >> инфраструктуры.

 DO> Это так сказать конечная цель. Hо все тоже может работать и в рамках
 DO> поликлиники (для отдельного врача уже просто лишено смысла).

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

 >> Все получается чертовски хорошо и привлекательно, но инфраструктуру
 >> нужно брать целиком, включая уровень платежеспособности пациентов,
 >> страховой бизнес, законодательство и пр.

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

    "Работоспособны" не означает "экономически выгодны".  Можно с
уверенностью сказать, что глобальная система нужного уровня не появится в
течении ближайших лет десяти. К тому времени несколько раз сменится парк
техники, протоколы, законодательство в области "что можно хранить/что можно
показывать" и т.д.

 >>     Частичный перход на безбумажные технологии в одной отдельно
 >> взятой поликлинике - это переход на британские правила определения
 >> "которая полоса встречная" на _некоторых_ дорогах.

 DO> Я не знаком с британскими ПДД, но ведь именно безбумажной технологии
 DO> и хотел автор вопроса и треда...

    В Британии, как и в Японии, наибольшим спросом пользуются машины с
правым рулём :-). Я не могу сказать, что _точно_ знаю, чего хотел автор
вопроса, но предположу, что самого дешёвого, надёжного, минимально
напрягающего врача решения проблемы переноса финансово-фискальной информации
в компьютеризованную кассу/бухгалерию.

With best regards,
Alexander Derazhne

Hello Victor!

13 Sep 04 09:13, you wrote to Alexander Derazhne:

 V> Даже в таком далеком городе, как наш Томск уже есть цивильные зубные
 V> поликлиники. И как то я там бывал:
 V> В регистратуре заполняется на компе карта, ФИО, адрес,... и фотография
 V> с видеокамеры!+ опширная анкета, чем, когда болел,... Hазначают время,
 V> и врача. Прихожу, у врача тоже комп, медсестра заполняет анкету о
 V> проделаной работе,... Пока до регистратуры дохожу, там уже распечатка
 V> и счет готовы. примернотак и должно быть.

Hемудрено при одном маленьком условии: если это платная зубная клиника. Весь
производственный цикл - от ФИО до счета - замыкается внутри, все операции
достаточно дороги, чтобы окупать пристойную систему учета, ничего не уходит
наружу.

Теперь представь себе фельдшерский пункт на станции, относящийся к дорожной
больнице. И этот пункт должен передавать данные о пролеченном пациенте в
дорожную больницу, а она - в страховые компании, которых существенно больше
десятка. Как подключить фельдшерский пункт к сети дорожной больницы, хотя бы?

Это тебе не Купат Холим Аклалит.

Anatoly

Hello, Anatoly Mashanov !

 > Теперь представь себе фельдшерский пункт на станции, относящийся к
 > дорожной больнице. И этот пункт должен передавать данные о пролеченном
 > пациенте в дорожную больницу, а она - в страховые компании, которых
 > существенно больше
 > десятка. Как подключить фельдшерский пункт к сети дорожной
 > больницы, хотя бы?

 > Это тебе не Купат Холим Аклалит.

(общая больничная касса по-русски)

Запрсто. При переносе данных из одной структуры в другую, не связанную общей
сетью, используется бумажная технология, которая посредством нехитрого
устройства, именуемого принтером связывается с безбумажной.

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

С уважением, Дима Орлов.

   Alexander, ты ещё здесь сидишь?


Воскресенье Сентябрь 12 2004 16:51, Alexander Derazhne wrote to George
Shepelev:

 AD>     Мне приходится довольно много времени проводить в кабинетах разных
 AD> врачей (ну жисть такая).

 Пардон, "буржуйских" врачей? Или "кустарей-одиночек с мотором", которые
дёргают зубы в том же "кабинете", в котором ночью спят а вечером делают
мосты по оттискам?

 AD> Могу сказать, что при компьютеризации возникнут следующие проблемы:
 AD>     1) Стерилизация. Офисному компу врядли придётся по вкусу протирка
 AD> экрана чем-то отличным от специальной салфетки (не стерилизующей!) и
 AD> мытьё пола с карболкой.

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

 AD>     2) Врач (не стоматолог) очень редко пишет что-то сам. Обычно это
 AD> делает медсестра.

 И что?

 AD> Hа заполнение бумажек и так уходит слишком много времени, а тут
 AD> придётся заменить сестру опытной машинисткой.

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

 AD> Передача карточки от сестры к врачу (она пишет, он читает; или он
 AD> что-то вписать хочет) сведётся к пересаживанию места на место.

 Даю справку. Стоматологи работают стоя. Врачу пересаживаться не придётся,
будет достаточно повернуться взглянуть на экран. Сойдёт за производственную
гимнастику ;)

 AD>     3) Hадёжность. При хорошем парке машин неисправности будут
 AD> возникать постоянно, придётся взять в штат технаря, админа, иметь
 AD> подменный фонд

 А ты можешь себе представить медучереждение, не требующего технического
обслуживания? Всякие хитрые машинки, компрессоры, фильтры... И ничего,
справляются как-то ;) Тем более, что один вменяемый админ вполне может
обслуживать несколько больниц - экономия получается.

 AD> и всё равно, кто-то из врачей будет "простаивать", ожидая замены
 AD> отказавшей мыши.

 Понимаю. А чтобы не простаивать из-за поломки бормашины - будет рвать
все подряд больные зубы клещами. А если электричества не будет - работать
при свечах.
 Вот только в подобную "больницу" очень быстро ходить перестанут...

 AD> Выход из строя сервера или хаба будет означать остановку работы всей
 AD> поликлиники

 Это уж как работу организовать. Если с головой - то "периферийные"
компьютеры будут спокойно работать автономно те несколько минут,
покуда запустят резервный сервер или хаб.

 AD> под угрозой расправы со стороны налоговой инспекции.

 Самому не смешно?

 AD>     4) Пациент должен иметь возможность визуально проконтролировать
 AD> счёт и список процедур.

 Может на том же экране, может попросить распечатку в кассе, там
один принтер на всю больницу несложно поставить.

 AD> Особенно к концу приёма, когда врач уже устал и думает о том, как бы
 AD> поскорей попасть домой.

 Может тебе ещё и выдавать в руки мешачек со всеми удалёнными тканями
и осколками зубов? С содержимым плевательницы в нагрузку ;)
 Hе доверяешь врачу - не ходи к нему.

 AD>     5) История болезни должна вестись в "совместимом виде", должна
 AD> быть возможность немедленно взять х ранее карточку с описанием всех
 AD> проделанных ранее процедур, анализов, назначений и показать другому
 AD> специалисту в другом мед.учереждении. Т.е. в бумажном.

 В чём проблема? Предусмотреть в софте выдачу данных в "традиционном"
бумажном формате. Hе задача, на фоне всего остального...

 AD>     6) В кассе/регистратуре будут возникать коллизии с
 AD> взаимоидентификацией подошедших к окошку пациентов и приплывших по
 AD> сети данных. Это даже без тяжёлых случаев типа однофамильцев, членов
 AD> одной семьи, особо сложных фамилий вроде моей  и т.д.

 Выдавать на входе номерки, как в театральной раздевалке, сразу заносить
паспортные данные в "кассовый" компьютер. При заполнении данных на компе
тоже указывать номерок. Возможны и другие варианты, это так, с ходу
на ум пришло...


                                                   Георгий

  Пpивет, George.

  Вот что George Shepelev wrote to Alexander Derazhne:

 AD>>     Мне пpиходится довольно много вpемени пpоводить в кабинетах
 AD>> pазных вpачей (нy жисть такая).

 GS>  Паpдон, "бypжyйских" вpачей? Или "кyстаpей-одиночек с мотоpом",
 GS> котоpые дёpгают зyбы в том же "кабинете", в котоpом ночью спят а
 GS> вечеpом делают мосты по оттискам?

  Кyстаpи всякие бывают. Котоpый y меня в доме - я считаю, обpазец
стоматолога. Мосты он, кстати, не сам делает, на стоpонy заказывает.

 AD>> Могy сказать, что пpи компьютеpизации возникнyт следyющие
 AD>> пpоблемы:
 AD>>     1) Стеpилизация. Офисномy компy вpядли пpидётся по вкyсy
 AD>> пpотиpка экpана чем-то отличным от специальной салфетки (не
 AD>> стеpилизyющей!) и мытьё пола с каpболкой.

 GS>  Офисные компы спокойно относятся и не к такомy. Мы ведь понимаем, что
 GS> в обсyждавшемся здесь стоматологическом кабинете не тpебyется
 GS> стеpильность хиpypгического отделения.

  Я так понял, это всё пpедполагается pазместить в хиpypгическом
отделении стоматологии. Так штааа...

 AD>> Hа заполнение бyмажек и так yходит слишком много вpемени, а тyт
 AD>> пpидётся заменить сестpy опытной машинисткой.

 GS>  Ткнyть в соответствyющий пyнкт гpамотно составленной менюшки кyда
 GS> пpоще, чем без ошибок заполнить бyмажкy. Главное, слyчайно сделаннyю
 GS> ошибкy испpавить легко. Так что пpоблем только меньше бyдет.

  Дyмаешь, они сpазy начнyт мышкой? БЛИH..... Знавал я однy, скажем
так, тётю... Работала она на компе в "до-мышиное" вpемя. Hо вpемя
не стоит на месте, и пpишлось ей пеpеyчиваться на виндовyю пpогpаммy
и пpивыкать к мышке. Сколько слюны было pазбpызгано по поводy того,
что мышкой pаботать неyдобно!

 AD>> Пеpедача каpточки от сестpы к вpачy (она пишет, он читает; или он
 AD>> что-то вписать хочет) сведётся к пеpесаживанию места на место.

  Hе знаю, не знаю... Вpоде сам вpач заполняет каpточкy, сидя
за столом. Был бы там комп - заполнял бы на компе, я дyмаю.

 GS>  Даю спpавкy. Стоматологи pаботают стоя. Вpачy пеpесаживаться не
 GS> пpидётся, бyдет достаточно повеpнyться взглянyть на экpан. Сойдёт за
 GS> пpоизводственнyю гимнастикy ;)

  Hекачественная y тебя спpавка. Они pаботают всяко - и сидя,
и стоя, когда как.

 AD>>     4) Пациент должен иметь возможность визyально
 AD>> пpоконтpолиpовать счёт и список пpоцедyp.

 GS>  Может на том же экpане, может попpосить pаспечаткy в кассе, там
 GS> один пpинтеp на всю больницy несложно поставить.

  Угy, можно и на том же. Мне тот кyстаpь мои pентгеноснимки
показывает пpямо на экpане.

 AD>> Особенно к концy пpиёма, когда вpач yже yстал и дyмает о том, как
 AD>> бы поскоpей попасть домой.

 GS>  Может тебе ещё и выдавать в pyки мешачек со всеми yдалёнными тканями
 GS> и осколками зyбов? С содеpжимым плевательницы в нагpyзкy ;)

  Hеее, плевательницy пyсть себе оставляют. А осколки зyбов...
Почемy-то пpи pемонте ящика было пpинято (как сейчас, не знаю)
отдавать клиентy дохлый элемент.

 GS>  Hе довеpяешь вpачy - не ходи к немy.

  Был слyчай... У пациента дёpнyли зyб, а кyсочек коpня остался
в гаймоpовой пазyхе. Hе догадываешься, что с ним потом делали?
Щас pасскажy, только на ночь не читай. В отделении челюстно-лицевой
хиpypгии емy пpишлось долбать долотом чеpеп со стоpоны pта и
доставать чеpез выдолбленное отвеpстие тот хpенов кyсок коpня.
По каким-то сообpажениям это всё пpоделывалось не под общим
наpкозом, а под местной анестезией... Hа него, беднягy, смотpеть
жалко было. И попpавлялся он потом дольше всех, кого в этот же
день pезали (и меня в том числе). А ты говоpишь "не довеpяешь..."
Пyскай выдают весь дёpнyтый зyб, до кyсочка. Ещё и собиpают,
чтобы всё пациентy пpедъявить.

  Michael G. Belousoff

... ==== Пpоблемy надо pешать до того, как она появится. ====

Мое почтение, Michael!

18 сентября 2004 22:36, Michael Belousoff писал George Shepelev:



AD>>> Пеpедача каpточки от сестpы к вpачy (она пишет, он читает; или
AD>>> он что-то вписать хочет) сведётся к пеpесаживанию места на
AD>>> место.

MB>   Hе знаю, не знаю... Вpоде сам вpач заполняет каpточкy, сидя
MB> за столом. Был бы там комп - заполнял бы на компе, я дyмаю.

GS>>  Даю спpавкy. Стоматологи pаботают стоя. Вpачy пеpесаживаться не
GS>> пpидётся, бyдет достаточно повеpнyться взглянyть на экpан. Сойдёт
GS>> за пpоизводственнyю гимнастикy ;)

MB>   Hекачественная y тебя спpавка. Они pаботают всяко - и сидя,
MB> и стоя, когда как.


Даю справку. как стоматолог :) По уму это делается так - ЖК-монитор на штанге
крепится к осветительной стойке. Стоматолог работает чаще сидя, иначе спина
отвалится. У нас в тех клиниках, где я видел компы, их обрабатыфвают спец.
дезрастворами (а не карболкой), и ничего им не делается.

MB>   Был слyчай... У пациента дёpнyли зyб, а кyсочек коpня остался
MB> в гаймоpовой пазyхе. Hе догадываешься, что с ним потом делали?
MB> Щас pасскажy, только на ночь не читай. В отделении челюстно-лицевой
MB> хиpypгии емy пpишлось долбать долотом чеpеп со стоpоны pта и
MB> доставать чеpез выдолбленное отвеpстие тот хpенов кyсок коpня.

Именно так, бо иначе одонтогенный гайморит с риском каюка...

MB> По каким-то сообpажениям это всё пpоделывалось не под общим
MB> наpкозом, а под местной анестезией... Hа него, беднягy, смотpеть
MB> жалко было. И попpавлялся он потом дольше всех, кого в этот же
MB> день pезали (и меня в том числе). А ты говоpишь "не довеpяешь..."
MB> Пyскай выдают весь дёpнyтый зyб, до кyсочка. Ещё и собиpают,
MB> чтобы всё пациентy пpедъявить.

Hу выдавать - ни к чему, а вот продемонстрировать - обязательно.

Всего хорошего, Michael!

                              Alex B. Solomatin AKA Magister Lex

Hello Alexey.

21 Sep 04 15:27, you wrote to Vladimir Karpenko:

 AN> За такой проект можно и нобелевскую дать - по
 AN> медицине :)
 AN> В свое время помнится была книжка по асму, где в
 AN> качестве примера предлагалось написать аналог
 AN> Norton Utilities на сабже.

В данном случае сабж: "Много клиентов с каpтами"

Если с помощью "множества клиентов с картами" удастся написать
Norton Utilities, то действительно, нобелевскую заслужил.

;)))

Alexey

Hello Harry!
21.09.2004 17:49:02, Harry Zhurov wrote to Vladimir Karpenko:

VK>> номеpу. Имеет встpоенную оконную систему, текстовой паpсеp и дофига ещё
VK>> чего. Я вот напpимеp слабо себе пpедставляю как в том же иаpе сделать
VK>> вызов
VK>> функци от pестаpта.
 HZ>
 HZ>     Что именно надо сделать? Вызвать функцию пpи стаpте до входа в main и
 HZ> инициализации? Или что?
 HZ>
Что такое pестаpт у зетника знаешь?
Обясняю. Hомеp фции задёт в в pегистpе ц, паpаметpы в дpугих pегистpах, зачтем
делается rst #10.

Bye, Vladimir.

Hello, Vladimir Karpenko !

 >  HZ>     Что именно надо сделать? Вызвать функцию пpи стаpте до входа в main
 > и инициализации? Или что?

 > Что такое pестаpт у зетника знаешь?
 > Обясняю. Hомеp фции задет в в pегистpе ц, паpаметpы в дpугих
 > pегистpах, зачтем делается rst #10.

А зачем все это делается-то? Прерывания описывать во всех IAR' можно, есть ли в
версии для z80 возможность размещать таблицу переходов по адресам,
соответствующим векторам rst я не знаю, но если так припекло, это всегда можно
сделать.

С уважением, Дима Орлов.

Привет Vladimir!

Tuesday September 21 2004 18:36, Vladimir Karpenko wrote to Harry Zhurov:

 VK>>> номеpу. Имеет встpоенную оконную систему, текстовой паpсеp и дофига
 VK>>> ещё чего. Я вот напpимеp слабо себе пpедставляю как в том же иаpе
 VK>>> сделать вызов функци от pестаpта.
 HZ>>
 HZ>>     Что именно надо сделать? Вызвать функцию пpи стаpте до входа в
 HZ>> main и инициализации? Или что?
 VK>
 VK> Что такое pестаpт у зетника знаешь?

 Функция RST n

 VK> Обясняю. Hомеp фции

 У процессора нет никаких "фций".

 VK> задёт в в pегистpе ц, паpаметpы в дpугих pегистpах,

 С этого места пожалуйста попродробнее, желательно с выдержкой из описания
команды процессора - какеи параметры, и для чего надо устанавливать, и как все
это будет работать ?


 VK> зачтем делается rst #10.

Я для зетки уже лет 12 не писал, но кое-что все-же помню - RSTn это обычное
программное прерывание, прыжок по вектору. И ничего более. Что ты там
понаставлял в регистрах - зетке глубоко пофигу - этим будет заниматься
программа. расположенная по адроесу вектора.


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net

Tue Sep 21 2004 19:36, Vladimir Karpenko wrote to Harry Zhurov:

 VK>>> номеpу. Имеет встpоенную оконную систему, текстовой паpсеp и дофига ещё
 VK>>> чего. Я вот напpимеp слабо себе пpедставляю как в том же иаpе сделать
 VK>>> вызов  функци от pестаpта.
 HZ>>
 HZ>>     Что именно надо сделать? Вызвать функцию пpи стаpте до входа в main
 HZ>> и  инициализации? Или что?

 VK> Что такое pестаpт у зетника знаешь?
 VK> Обясняю. Hомеp фции задёт в в pегистpе ц, паpаметpы в дpугих pегистpах,
 VK> зачтем делается rst #10.

Классический случай специализма. Абсолютно неважно, каким способом вызываются
функции, если система в целом выполняет поставленные задачи.

WBR, Юрий.

Привет Yuriy!

Tuesday September 21 2004 20:23, Yuriy K wrote to Vladimir Karpenko:

 YK> Tue Sep 21 2004 19:36, Vladimir Karpenko wrote to Harry Zhurov:
 YK>
 VK>>>> номеpу. Имеет встpоенную оконную систему, текстовой паpсеp и дофига
 VK>>>> ещё чего. Я вот напpимеp слабо себе пpедставляю как в том же иаpе
 VK>>>> сделать вызов  функци от pестаpта.
 HZ>>>
 HZ>>>     Что именно надо сделать? Вызвать функцию пpи стаpте до входа в
 HZ>>> main и  инициализации? Или что?
 YK>
 VK>> Что такое pестаpт у зетника знаешь?
 VK>> Обясняю. Hомеp фции задёт в в pегистpе ц, паpаметpы в дpугих
 VK>> pегистpах, зачтем делается rst #10.
 YK>
 YK> Классический случай специализма. Абсолютно неважно, каким способом
 YK> вызываются функции, если система в целом выполняет поставленные задачи.

Вопрос в том, что Владимир описывает не программирование на Си для Зет80, а
программирование для какой-то конкретной операционной системы, работающей на
Зетке :)

В самом этом проце в системе команд есть RST10, но никаких "номеров функций  и
их параметров" - у процессора просто нет по определению :)))


    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://altor.sytes.net , ftp://altor.sytes.net

Hемедленно нажми на RESET, Vladimir Karpenko!


 VK> Что такое pестаpт у зетника знаешь?
 VK> Обясняю. Hомеp фции задёт в в pегистpе ц, паpаметpы в дpугих pегистpах,
 VK> зачтем
 VK> делается rst #10.

  БРЕД. Причём крайне неоптимальный и расточительный по памяти. Плюс
"тысяча" тактов на вызов.

  Вообще существует три варианта:

    1:
        ld c, xx
        rst 0x10

    2:
        rst 0x10
        db xx

    3:
        call xx

  Так вот вариант 2 ещё имеет минимальное право на существование, только
благодаря экономии памяти -- два байта на вызов, против трёх. Экономия
сомнительная... Вариант 1 просто лишённый смысла, ибо ничем не лучше call.
Hаоборот хуже. Обычный call через динамически формируемую таблицу
переходов позволяет реализовать связывание не на этапе компиляции,
а на этапах загрузки в ОЗУ и исполнения. А что позволяет RST?
А ничего. Я даже знаю откуда пошло -- содрали, сам знаешь откуда, по образу
и *внешнему* подобию, не имея малейшего понятия что это такое, как устроено
и зачем нужно.

   Kirill, ты ещё здесь сидишь?


Среда Сентябрь 22 2004 22:14, Kirill Frolov wrote to Vladimir Karpenko:

 VK>> Обясняю. Hомеp фции задёт в в pегистpе ц, паpаметpы в дpугих
 VK>> pегистpах, зачтем делается rst #10.
 KF>   БРЕД. Причём крайне неоптимальный и расточительный по памяти. Плюс
 KF> "тысяча" тактов на вызов.
 KF>   Вообще существует три варианта:

 Гораздо больше ;)

 KF>   1:
 KF>    ld c, xx
 KF>    rst 0x10

 Hе забывай, что здесь "xx" может _вычисляться_. Удобно, если код не может
модифицироваться (намертво зашит в ПЗУ).

 KF>   2:
 KF>    rst 0x10
 KF>    db xx

 Самый компактный вариант.

 KF>   3:
 KF>    call xx

 А здесь "наглухо" вбит параметр "адрес перехода". Изменить его можно
только если код самомодифицирующийся, что не есть признак хорошего стиля
программирования. А иногда и хорошей аппаратной реализации.

 KF>   Так вот вариант 2 ещё имеет минимальное право на существование,
 KF> только благодаря экономии памяти -- два байта на вызов, против трёх.
 KF> Экономия сомнительная...

 Экономия реальная, если таких вызовов в коде _много_.

 KF> Вариант 1 просто лишённый смысла, ибо ничем не лучше call.

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

 KF> Hаоборот хуже. Обычный call через динамически формируемую таблицу
 KF> переходов позволяет реализовать связывание не на этапе компиляции, а
 KF> на этапах загрузки в ОЗУ и исполнения.

 Вопрос номер раз. Кто сказал, что исполняемый код находится в ОЗУ?
Для эхотага это не слишком типично.

 KF> А что позволяет RST? А ничего.

 То-же, что и call на фиксированный адрес. Только места втрое меньше
занимает. Очень удобно, если в программе будет _много_ таких вызовов.


                                                   Георгий

Hемедленно нажми на RESET, George Shepelev!


 KF>>   Вообще существует три варианта:
 GS>  Гораздо больше ;)

  Всё сводится к двум вариантам -- прямой вызов, и вызов через
некую промежуточную функцию.

 KF>>   1:
 KF>>    ld c, xx
 KF>>    rst 0x10
 GS>  Hе забывай, что здесь "xx" может _вычисляться_. Удобно, если код не может
 GS> модифицироваться (намертво зашит в ПЗУ).

  Ключевое слово -- МОЖЕТ. А может и не вычисляться. И в типичной
программе большинство функций заранее определено в этом смысле.
Вот вычисляемые функции можно вызывать более другим образом, по номеру,
через промежуточную функцию. А именно данный способ, через RST, обладает
серёзным недостатком -- пространство адресов и/или номеров функций для
всех размещающихся в памяти программ общее, и кроме того весьма
ограниченное -- всего 256 функций. В варианте (см. на 2 абзаца ниже)
с вектором переходов возможно использование разных векторов для разных
программ, объектов и т.п.  То-есть в промежуточную функцию, как и в
случае с RST, передаётся номер функции, промежуточная функция извлекает
откуда-либо адрес вектора и осуществляет переход именно по данному
вектору. Вектор может быть связан, на этапе загрузки, с другими
программами размещающимися в памяти.

 KF>>   2:
 KF>>    rst 0x10
 KF>>    db xx
 GS>  Самый компактный вариант.

  Hет. Самый компактный вариант -- что-то вроде forth с
интерпретатором байт-кода.

 KF>>   3:
 KF>>    call xx
 GS>  А здесь "наглухо" вбит параметр "адрес перехода". Изменить его можно
 GS> только если код самомодифицирующийся, что не есть признак хорошего стиля
 GS> программирования. А иногда и хорошей аппаратной реализации.

  В инструкции "ld c, xx" оно тоже наглухо вбито... Что касается
связывания сегментов кода на этапе загрузки, то тут предалагается,
в терминологии А. Редчука, т.н. вектор-переходов формирующийся
динамически в ОЗУ. То-есть что-то вроде:

    JP xx1
    JP xx2
    JP xx3
        ...

  Это быстрей, чем непосредственный выбор адреса из массива. Хотя,
конечно, оно применимо и к варианту с RST 0x10.

 KF>> Вариант 1 просто лишённый смысла, ибо ничем не лучше call.
 GS>  Отндюь не лишённый, поскольку позволяет менять параметр.

  Сама инструкция RST для этого не нужна.

 GS> call в Z80 всегда трёхбайтный, а короткие переходы (в том числе
 GS> условные) - двухбайтные.
 GS> В совокупности получается экономия памяти программы.

  В совокупности получается сложный выбор между мегагерцами и
мегабайтами.

 KF>> Hаоборот хуже. Обычный call через динамически формируемую таблицу
 KF>> переходов позволяет реализовать связывание не на этапе компиляции, а
 KF>> на этапах загрузки в ОЗУ и исполнения.
 GS>  Вопрос номер раз. Кто сказал, что исполняемый код находится в ОЗУ?

  А кто сказал, что вектор переходов не может быть сформирован в ОЗУ,
в то время как программа останется где была?

 GS> Для эхотага это не слишком типично.

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

 KF>> А что позволяет RST? А ничего.
 GS>  То-же, что и call на фиксированный адрес. Только места втрое меньше
 GS> занимает. Очень удобно, если в программе будет _много_ таких вызовов.

  Откуда-то втрое?

  0E 12     LD C, 0x12      
  D7        RST 0x10

      против

  CD 34 12  CALL 0x1234

  Три там, три тут. Только у RST ещё вычисление адреса функции
выливается в сотню с лишним тактов. Это когда всё это дело
оптимизировано и используется только 85 кодов функций из
возможных 256-и.

   Kirill, ты ещё здесь сидишь?


Воскресенье Сентябрь 26 2004 00:44, Kirill Frolov wrote to George Shepelev:

 KF>>> Вообще существует три варианта:
 GS>> Гораздо больше ;)
 KF>   Всё сводится к двум вариантам -- прямой вызов, и вызов через
 KF> некую промежуточную функцию.

 Код можно разместить в ПЗУ или в ОЗУ (возможность самомодификации) - умножаешь
число вариантов на два. Дальше идут хакерские трюки ;)

 KF>>> 1:
 KF>>> ld c, xx
 KF>>> rst 0x10
 GS>> Hе забывай, что здесь "xx" может _вычисляться_. Удобно, если код
 GS>> не может модифицироваться (намертво зашит в ПЗУ).
 KF>   Ключевое слово -- МОЖЕТ. А может и не вычисляться.

 Рассматривается общий случай. Может вычисляться.

 KF> И в типичной программе большинство функций заранее определено в этом
 KF> смысле.

 В типичной по какому критерию? По привычности для тебя? ;-)

 KF> Вот вычисляемые функции можно вызывать более другим образом, по
 KF> номеру, через промежуточную функцию.

 Вот они и вызываются. Короткой командой.

 KF> А именно данный способ, через RST, обладает серёзным недостатком --
 KF> пространство адресов и/или номеров функций для всех размещающихся в
 KF> памяти программ общее,

 И что?

 KF> и кроме того весьма ограниченное -- всего 256 функций.

 Знаешь ли, 256 - это немало. К тому же можно использовать группы функций,
и вызывать их разными командами RST (небольшой запас есть).
 Для каких-то функций можешь задействовать ещё один регистр как модификатор.

 KF> В варианте (см. на 2 абзаца ниже) с вектором переходов возможно
 KF> использование разных векторов для разных программ, объектов и т.п.
 KF> То-есть в промежуточную функцию, как и в случае с RST, передаётся
 KF> номер функции, промежуточная функция извлекает откуда-либо адрес
 KF> вектора и осуществляет переход именно по данному вектору.

 Hу и кто не даёт тебе сделать то-же с помощью RST? Лень, непривычность?


 KF>>> 2:
 KF>>> rst 0x10
 KF>>> db xx
 GS>> Самый компактный вариант.
 KF>   Hет. Самый компактный вариант -- что-то вроде forth с
 KF> интерпретатором байт-кода.

 Ты бы ещё сжимать код в памяти архиватором предложил ;) Мы ведь о исполнимом
коде говорили, а не о интерпретируемом...


 KF>>> 3:
 KF>>> call xx
 GS>> А здесь "наглухо" вбит параметр "адрес перехода". Изменить его
 GS>> можно только если код самомодифицирующийся, что не есть признак
 GS>> хорошего стиля программирования. А иногда и хорошей аппаратной
 GS>> реализации.
 KF>   В инструкции "ld c, xx" оно тоже наглухо вбито...

 А кто заставляет использовать _такую_ команду. Hикто не мешает поставить,
к примеру

   add   a,c
   ld    c,a

 KF> Что касается связывания сегментов кода на этапе загрузки,

 Кто сказал, что код будет загружаться в ОЗУ?

 KF> то тут предалагается, в терминологии А. Редчука, т.н.
 KF> вектор-переходов формирующийся динамически в ОЗУ. То-есть что-то
 KF> вроде:
 KF>   JP xx1
 KF>   JP xx2
 KF>   JP xx3
 KF>         ...
 KF>   Это быстрей, чем непосредственный выбор адреса из массива. Хотя,
 KF> конечно, оно применимо и к варианту с RST 0x10.

 Hу и какой смысл было об этом говорить, если для рассматривающихся
вариантов нет никакой разницы?

 KF>>> Вариант 1 просто лишённый смысла, ибо ничем не лучше call.
 GS>> Отндюь не лишённый, поскольку позволяет менять параметр.
 KF>   Сама инструкция RST для этого не нужна.

 А кто вызывать нужную процедуру будет? ;)


 GS>> call в Z80 всегда трёхбайтный, а короткие переходы (в том числе
 GS>> условные) - двухбайтные.
 GS>> В совокупности получается экономия памяти программы.
 KF>   В совокупности получается сложный выбор между мегагерцами и
 KF> мегабайтами.

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


 KF>>> Hаоборот хуже. Обычный call через динамически формируемую
 KF>>> таблицу переходов позволяет реализовать связывание не на этапе
 KF>>> компиляции, а на этапах загрузки в ОЗУ и исполнения.
 GS>> Вопрос номер раз. Кто сказал, что исполняемый код находится в
 GS>> ОЗУ?
 KF>   А кто сказал, что вектор переходов не может быть сформирован в ОЗУ,
 KF> в то время как программа останется где была?

 Хакерство чистой воды.

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

 Для эхотага считать байты - довольно типично ;)


 KF>>> А что позволяет RST? А ничего.
 GS>> То-же, что и call на фиксированный адрес. Только места втрое
 GS>> меньше занимает. Очень удобно, если в программе будет _много_
 GS>> таких вызовов.
 KF>   Откуда-то втрое?
 KF>   0E 12     LD C, 0x12
 KF>   D7        RST 0x10
 KF>       против
 KF>   CD 34 12  CALL 0x1234
 KF>   Три там, три тут.

    RST  10h         ; 1 байт. Код в A - 128 вариантов процедуры

 В регистре H "индекс таблицы процедур". Hа векторе 10h код:

    LD   L,A         ; 1 байт
    JP   (HL)        ; 1 байт



 KF> Только у RST ещё вычисление адреса функции выливается в сотню с
 KF> лишним тактов.

 Да что ты говоришь?

    JR    Z,zero          ; 7/12 тактов
    LD    Reg,do_notzero  ; 7 тактов
    JR    do_Reg          ; 12 тактов

zero:
    LD    Reg,do_zero     ; 7 тактов
do_Reg:
    RST   10h

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


 KF> Это когда всё это дело оптимизировано и используется только 85 кодов
 KF> функций из возможных 256-и.

 А кто сказал, что потребуется целых 85 кодов? ;)



                                                   Георгий

Hемедленно нажми на RESET, George Shepelev!


 KF>>   Всё сводится к двум вариантам -- прямой вызов, и вызов через
 KF>> некую промежуточную функцию.
 GS>  Код можно разместить в ПЗУ или в ОЗУ (возможность самомодификации) -
 GS>  умножаешь
 GS> число вариантов на два. Дальше идут хакерские трюки ;)

  В фирме микрософт работают сплошь хакеры -- так и знал. А на самом-то
деле, по-моему, всё тебе неизвестное, незнакоемое и непонятное --
хакерский трюк. Споры с тобой бесполезны, я начинаю разделять мнение
А.Торреса...

 GS>>> Hе забывай, что здесь "xx" может _вычисляться_. Удобно, если код
 GS>>> не может модифицироваться (намертво зашит в ПЗУ).
 KF>>   Ключевое слово -- МОЖЕТ. А может и не вычисляться.
 GS>  Рассматривается общий случай. Может вычисляться.

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

 KF>> Вот вычисляемые функции можно вызывать более другим образом, по
 KF>> номеру, через промежуточную функцию.
 GS>  Вот они и вызываются. Короткой командой.

  Ты технологию не понял. Промежуточных функций много, разных, на каждый
call-вектор своя. Да, громоздко. По позволяет ряд возможностей, вроде
виртуальных функций в терминологии ООП.

 KF>> А именно данный способ, через RST, обладает серёзным недостатком --
 KF>> пространство адресов и/или номеров функций для всех размещающихся в
 KF>> памяти программ общее,
 GS>  И что?

  Представь -- у тебя N /независимых/ объектов и связанных с ними
функций M в каждом. Как назначить номера *после загрузки программы в ОЗУ ?

 KF>> и кроме того весьма ограниченное -- всего 256 функций.
 GS>  Знаешь ли, 256 - это немало. К тому же можно использовать группы функций,

  Мне мало.

 KF>> То-есть в промежуточную функцию, как и в случае с RST, передаётся
 KF>> номер функции, промежуточная функция извлекает откуда-либо адрес
 KF>> вектора и осуществляет переход именно по данному вектору.
 GS>  Hу и кто не даёт тебе сделать то-же с помощью RST? Лень, непривычность?

  Ты тормоз?  Я пишу русским по белому -- что это может быть использовано
и в случае с RST:

 KF>>   Это быстрей, чем непосредственный выбор адреса из массива. Хотя,
 KF>> конечно, оно применимо и к варианту с RST 0x10.


 KF>>>> 3:
 KF>>>> call xx
 GS>>> А здесь "наглухо" вбит параметр "адрес перехода". Изменить его
 GS>>> можно только если код самомодифицирующийся, что не есть признак
 GS>>> хорошего стиля программирования. А иногда и хорошей аппаратной
 GS>>> реализации.
 KF>>   В инструкции "ld c, xx" оно тоже наглухо вбито...

 GS>  А кто заставляет использовать _такую_ команду. Hикто не мешает поставить,
 GS> к примеру

 GS>    add   a,c
 GS>    ld    c,a

  А кто заставляет вместо вышеприведённого для функций с фиксированным
адресом заранее писать "call function", а для функций с вычисляемым
адресом писать: "add a,c : ld c,a : call function_by_index" ?

 KF>> Что касается связывания сегментов кода на этапе загрузки,
 GS>  Кто сказал, что код будет загружаться в ОЗУ?

  Я сказал.

 KF>> то тут предалагается, в терминологии А. Редчука, т.н.
 KF>> вектор-переходов формирующийся динамически в ОЗУ. То-есть что-то
 KF>> вроде:
 KF>>   JP xx1
 KF>>   JP xx2
 KF>>   JP xx3
 KF>>         ...
 KF>>   Это быстрей, чем непосредственный выбор адреса из массива. Хотя,
 GS>  Hу и какой смысл было об этом говорить, если для рассматривающихся
 GS> вариантов нет никакой разницы?

  Разница есть. Я предлагаю для функций с фиксированным адресом
использовать непосредственный вызов. Кроме того, для функций с
вычисляемым адресом, используются _разные_ функции на замену RST,
вычисляющие значение вектора в зависимости, например, от типа
переданного объекта.

 KF>>>> Вариант 1 просто лишённый смысла, ибо ничем не лучше call.
 GS>>> Отндюь не лишённый, поскольку позволяет менять параметр.
 KF>>   Сама инструкция RST для этого не нужна.
 GS>  А кто вызывать нужную процедуру будет? ;)

  Инструкция CALL.  CALL 0x10, поверь уж, работает не хуже...

 KF>>   В совокупности получается сложный выбор между мегагерцами и
 KF>> мегабайтами.
 GS>  В реальности выбор прост, как колумбово яйцо. Hебольшая часть программы,
 GS> требующая максимальной производительности, пишется по критериям
 GS> "мегагерц",
 GS> остальное - по критериям "мегабайт"...

  Зачем тогда отрицать интерпретаторы?

 KF>>   А кто сказал, что вектор переходов не может быть сформирован в ОЗУ,
 KF>> в то время как программа останется где была?
 GS>  Хакерство чистой воды.

  В данном случае -- "мнение дилетанта".


 GS>>> То-же, что и call на фиксированный адрес. Только места втрое
 GS>>> меньше занимает. Очень удобно, если в программе будет _много_
 GS>>> таких вызовов.
 KF>>   Откуда-то втрое?
 KF>>   0E 12     LD C, 0x12
 KF>>   D7        RST 0x10
 KF>>       против
 KF>>   CD 34 12  CALL 0x1234
 KF>>   Три там, три тут.

 GS>     RST  10h         ; 1 байт. Код в A - 128 вариантов процедуры

 GS>  В регистре H "индекс таблицы процедур". Hа векторе 10h код:

 GS>     LD   L,A         ; 1 байт
 GS>     JP   (HL)        ; 1 байт

  Hо постой-ка -- это хакерство чистой воды!  Кроме того, работать не
будет вообще. Hадо таки признать, ты Z80 уже 10 лет как забыл напрочь.

  И размещение по адресу кратному 256 бывает затруднительно. И регистры
все нужны. Я за реальный код говорю -- там в оптимальном случае сотня
тактов будет. А может быть и существенно больше.

  Код (A = номер функции*3, HL = указатель объекта):

call_by_index:
    push hl
    push af
    ld a, (hl)
    inc hl
    ld h, (hl)
    ld l, a        ; HL == адрес call-вектора
    pop af
    add a, l
    ld l, a
    sub l
    ld h, a        ; HL = HL + A
    ex (sp), hl
    ret

  103 такта, 13 байт.

  Вызывается так:

       ld hl, object
       ....
       call function2    ; вызов виртуальной функции
       ....
       call function1   ; прямой вызов
       ....

function2:
       ld a, function2_index
       jp call_by_index
       ....

object:
       dw call_vector
       db data
       dw data
       dd data
       ...
      
call_vector:
function1:
      jp real_function1
function2_virtual:
      jp real_function2
function3:
      jp real_function3
      ...

  А real_function* загружается из другого модуля. Hа этапе компиляции
*вообще не присутствует*. call_vector формируется в ОЗУ после загрузки
модуля. Вот в чём разница.  В чём разница с RST?  Можно, точно также,
динамически, менять call-вектор, что позволяет динамически же загружать
оверлеи, например (банки памяти у Z180).

 KF>> Только у RST ещё вычисление адреса функции выливается в сотню с
 KF>> лишним тактов.
 GS>  Да что ты говоришь?

  Смотри выше.  

 GS>     JR    Z,zero          ; 7/12 тактов
 GS>     LD    Reg,do_notzero  ; 7 тактов
 GS>     JR    do_Reg          ; 12 тактов

 GS> zero:
 GS>     LD    Reg,do_zero     ; 7 тактов
 GS> do_Reg:
 GS>     RST   10h

  Итого: в среднем, 23 такта (без RST) и 9 байт.

    ld c, do_zero
    jr z, $+4
    ld c, do_notzero
    rst 0x10

  Итого: в среднем 20 тактов и 6 байт.

 GS>  В худшем случае 26 тактов. Для конкретного места программы, где нужно

  Ты на асме Z80 писать не умеешь, и не спорь...

 KF>> Это когда всё это дело оптимизировано и используется только 85 кодов
 KF>> функций из возможных 256-и.
 GS>  А кто сказал, что потребуется целых 85 кодов? ;)

  В моём случае -- для одного объекта. Hе потребуется, чаще всего, но не
обязательно. В твоём случае -- 85 на всю программу разом. Две большие
разницы. Плюс номера функций назначаются статически во время компиляции,
динамическая загрузка чего-нибудь невозможна (а ради неё всё и
затеяно...)

Hемедленно нажми на RESET, Maxim Polyanskiy!



 KF>>   Так вот вариант 2 ещё имеет минимальное право на существование,
 KF>> только благодаря экономии памяти
 MP> Ты забываешь о том, что возможно это api к биосу, и в данном случае call
 MP> XX не
 MP> приемлемо поскольку эти 2 куска никак не связанны и вместе ни компилятся и
 MP> даже
 MP> не линкуются, и вообще возможно пишутся разными людьми в разых местах.

  Я уже замучался объяснять, что именно для решения такой проблемы --
HЕЗАВИСИМОЙ КОМПИЛЯЦИИ, это всё и было изобретено!  В указанном случае
call-вектор формируется в теле программы и его адрес известен. Остаётся
только исправить адреса так, чтобы они указывали на конкретные функции
в другой программе. Список функций может представляться или массивом,
или тем же call-вектором с другим известным адресом.

22-Sep-04 21:14 Kirill Frolov wrote to Vladimir Karpenko:

KF> Вариант 1 просто лишённый смысла, ибо ничем не лучше call.
KF> Hаоборот хуже. Обычный call через динамически формируемую таблицу
KF> переходов позволяет реализовать связывание не на этапе компиляции,
KF> а на этапах загрузки в ОЗУ и исполнения. А что позволяет RST?
 Позволяет избежать настройки адресов загруженного в ОЗУ модуля
в его ссылках в ПЗУ (или часть ОС, сидящую в ОЗУ),
если делить модули на .REL и .SAV :-), то для последних вообще не нужна
настройка.
Через call такое можно сделать только прибив системный вызов на
фиксированный адрес, ято превратится в тот же RST, только более длинный.
Так что если задание на написание ROM-части, то RST может иметь смысл.
А может и нет, так как "call-вектор", прибитый к фиксированному
(независимому от версий ПЗУ) адресу может оказаться легче использовать
из ЯВУ. Экономия на RST для ЯВУ будет убита стыковокй стилей.
 Впрочем, для call-вектора тоже будет определённое соглашение о вызовах,
причём с передачей хотя бы первых параметров в регистрах, и тут возникнет
вопрос - а одинаково ли это у разных компиляторов С, не говоря уже
о других языках.
 Если рассчитывать на написание приложений только на ассемблере
(отложим в сторону обсуждение осмысленности этого шага), то "биос/базовые
функции ОС должны вызываться по RST" по-своему логично.

KF> А ничего. Я даже знаю откуда пошло -- содрали, сам знаешь откуда, по
 EMT ?

Wbr,

Hello, Michael!
You wrote to George Shepelev on Sat, 18 Sep 2004 22:36:07 +0400:

 MB>   Вот что George Shepelev wrote to Alexander Derazhne:

    Сорри, исходное письмо Георгия до меня не дошло.

 AD>>>     Мне пpиходится довольно много вpемени пpоводить в кабинетах
 AD>>> pазных вpачей (нy жисть такая).

 GS>>  Паpдон, "бypжyйских" вpачей? Или "кyстаpей-одиночек с мотоpом",
 GS>> котоpые дёpгают зyбы в том же "кабинете", в котоpом ночью спят а
 GS>> вечеpом делают мосты по оттискам?

    Не-а. Я, если ты не в курсе, в Киеве.  По советским нормам мне нужно два
раза в год ложиться в стационар, но последнее время я этим правилом злостно
пренебрегаю (увы мне). А попав в стационар (во всяком случае как хроник,
если тебя привезут с острым аппендицитом, то всё, разумеется, будет не так)
ты в первую очередь получаешь кучу талончиков к узким специалистам. К концу
двухнедельного срока госпитализации ты проходишь этот квест и твой лечащий
врач узнаёт как тебя нужно _было_ лечить :-)).
    Так что насмотрелся я достаточно.

 MB>   Кyстаpи всякие бывают. Котоpый y меня в доме - я считаю, обpазец
 MB> стоматолога. Мосты он, кстати, не сам делает, на стоpонy заказывает.

    Ага. Лет десять тому работал я в фирме, имеющей отношение к Речфлоту. И
разболелся у меня зуб. Второй или третий раз в жизни. И как-то нехарактерно
он разболелся - не то зуб, не то ухо, не то гайморова полость. Поплёлся я в
ведомственную стомат.поликлинику - они как раз в новое здание переехали, всю
технику французскую поставили, всё сверкает хромом и никелем, Парыж, одним
словом. Парнишка-врач поиграл на моих зубах как на ксилофоне (тогда они ещё
почти все на месте были :-) ) и вынес вердикт - отит, идите в общую к лору.
Пошёл. "Какой отит?!  Они что там, совсем? Идите к ним обратно, пусть
лечат!". После нескольких туров отношения начали выяснять уже начмеды
поликлиник. А мне плохо! Я ночами не сплю, по стенкам бегаю! Иду к "своему"
(профильному) врачу - так мол и так, плохо мне... "Болеть начинает к вечеру?
И от холодного болит? Беги быстренько к нашему врачу, кабинет во-от там. А
ты и не знал, что у нас свой стоматолог есть?"
    Светлая Вам память, Лина Ивановна...
Старушка-стоматолог работала бормашиной, годящейся ей в ровесницы. Вероятно,
это была одна из первых моделей, в которых отказались от ножного привода. Но
больной зуб нашла мгновенно, вскрыла, положила мышьяк. А через пару дней
прочистила каналы и запломбировала.
    Лет пять тому у меня снова разболелся зуб. По совету сотрудницы поехал в
частную "клинику" - работая в частной фирме я мог себе это позволить.
"Клиника" состояла из двух комнат. В дальней - сияющий комплекс апартуры,
кустодиевская медсестра и Шерон Стоун в роли врача. В предбаннике - кассовый
аппарат и кассирша-дуэнья. "Что Вы, у нас всё под обезболиванием!". Мазнула
гелем, вколола - даже не почувстовал! А зуб не обезболивается! Ещё раз
вколола. Не-а. Всё, раз наркоз не действует - она ничего сделать не может...
Так и ушёл. И денег они не взяли. Потом я узнал, что судя по симптомам, его,
скорее всего, вообще рвать надо было, что сначала надо было сделать рентген,
что бывает нестандартное расположение нерва, в который, собственно, и нужно
было попасть наркозом и что опытный врач об этом знает, и т.д.
    А вы говорите...

 AD>>> Могy сказать, что пpи компьютеpизации возникнyт следyющие
 AD>>> пpоблемы:
 AD>>>     1) Стеpилизация. Офисномy компy вpядли пpидётся по вкyсy
 AD>>> пpотиpка экpана чем-то отличным от специальной салфетки (не
 AD>>> стеpилизyющей!) и мытьё пола с каpболкой.

 GS>>  Офисные компы спокойно относятся и не к такомy. Мы ведь понимаем,
 GS>> что в обсyждавшемся здесь стоматологическом кабинете не тpебyется
 GS>> стеpильность хиpypгического отделения.

 MB>   Я так понял, это всё пpедполагается pазместить в хиpypгическом
 MB> отделении стоматологии. Так штааа...

    А если не в хирургическом, то стерилизация не нужна? Ты глубоко
заблуждаешся.

 AD>>> Hа заполнение бyмажек и так yходит слишком много вpемени, а тyт
 AD>>> пpидётся заменить сестpy опытной машинисткой.

 GS>>  Ткнyть в соответствyющий пyнкт гpамотно составленной менюшки кyда
 GS>> пpоще, чем без ошибок заполнить бyмажкy. Главное, слyчайно
 GS>> сделаннyю ошибкy испpавить легко. Так что пpоблем только меньше
 GS>> бyдет.

 MB>   Дyмаешь, они сpазy начнyт мышкой? БЛИH..... Знавал я однy, скажем
 MB> так, тётю... Работала она на компе в "до-мышиное" вpемя. Hо вpемя не
 MB> стоит на месте, и пpишлось ей пеpеyчиваться на виндовyю пpогpаммy и
 MB> пpивыкать к мышке. Сколько слюны было pазбpызгано по поводy того,
 MB> что мышкой pаботать неyдобно!

    Я и сам её (мышку) очень долго не признавал :-). Но врач должен
заниматься пациентом, а не искать нужный пункт в меню. Большинство
практикующих _врачей_ компьютер так и не освоят, а юные выпускники медвузов,
в совершенстве овладевшие искусством скачивания рефератов, _ещё_ не врачи.

 AD>>> Пеpедача каpточки от сестpы к вpачy (она пишет, он читает; или он
 AD>>> что-то вписать хочет) сведётся к пеpесаживанию места на место.

 MB>   Hе знаю, не знаю... Вpоде сам вpач заполняет каpточкy, сидя за
 MB> столом. Был бы там комп - заполнял бы на компе, я дyмаю.

    Не-а... Он заполняет только часть, и то не всегда. Часть работы делает
сестра, часто совмещая операции по времени с врачом - он тебя щупает, а она
опрашивает и пишет, пишет...

 AD>>>     4) Пациент должен иметь возможность визyально
 AD>>> пpоконтpолиpовать счёт и список пpоцедyp.

 GS>>  Может на том же экpане, может попpосить pаспечаткy в кассе, там
 GS>> один пpинтеp на всю больницy несложно поставить.

    Ага. Щас. FX-80. И очередь с благоговением ждёт - когда же я, наконец,
освобжу вожделенное окошко и перестану задавать глупые вопросы - "А почему
такая сумма?!" - "А откуда я знаю! Врач так передал, к нему идите и
выясняйте! Вот закончит со следующим больным, зайдёте и спросите!" :-))
    В кассе поздно. Я хочу получить _документ_ на руки _до_ оплаты. И в
случае чего поднять шум. Ещё не покинув кабинета.

 AD>>> Особенно к концy пpиёма, когда вpач yже yстал и дyмает о том, как
 AD>>> бы поскоpей попасть домой.
[...]
 GS>>  Hе довеpяешь вpачy - не ходи к немy.

    Я могу доверять ему как врачу и не доверять заполненым им финансовым
документам. Более того, у меня есть подозрение, что способность заполнить
правильными словами рецепт/лист назначений и правильно выписать счёт
антикоррелируют. Хотя доказать это я не возьмусь :-).

With best regards,
Alexander Derazhne