LPC2xxx - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Re: LPC2xxx
Привет Harry!

14 Nov 05 17:02, Harry Zhurov писал Alex Mogilnikov:

 HZ>     Дело не в драйвере, а в том, что то, что у тебя хорошо идет на PC,
 HZ> на МК будет идти плохо из-за быстродействия (либо нехватки других
 HZ> ресурсов - памяти, к примеру). Т.е. не в функциональном соответствии
 HZ> дело, не в завязке на конкретные аппаратные особенности, а просто в
 HZ> нагрузке на CPU и требованиях по быстродействию.

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

 HZ>  Я уже говорил, что
 HZ> писание под МК очень отличается от писания под PC в первую очередь
 HZ> расстановкой акцентов и учетом быстродействия и других ресурсов.

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

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

    Еще пример. Hедавно один человек предъявил мне примерно такой код для
вывода строк заголовка HTTP ответа:

for(iterator i = begin(); i != end(); i++)
{
    std::string s = i->first + ": " + i->second + "\r\n";
    fputs(s.c_str(), stream);
}

    Hе так уж важно знать, для PC это пишется, или для МК, чтобы заметить, что
создание и последующее удаление четырех (у него было 4, я считал) временных
строк с выделением памяти из кучи и копированием данных с места на место во
много раз дороже четырех последовательных вызовов fputs().

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Закрой свой Ворд!

LPC2xxx
Fri Nov 11 2005 15:12, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 AM>> union тут причем потому, что в данном случае именно он позволяет
 AM>> представить данные в виде линейного буфера из байтов, а потом обработать
 AM>>  этот буфер, как структуру с соответствующими полями.

 EK> фига,
 EK> представить структуру в виде линейного буфера из байтов можно и без
 EK> union'а, при этом грабли от выравнивания все равно останутся.

Hет. Просто нужно правильно писать код. Пользоваться _только_ байтами
и преобразовывать многобайтные данные явным образом.

 EK> Кстати да - неиспользование #pagma pack или аналогов или неявное
 EK> использование - это 100% повторяемый глюк при портировании.

Hет. См. выше.

WBR, Yuriy.


Re: LPC2xxx
Привет Harry!

14 Nov 05 09:08, Harry Zhurov писал Alex Mogilnikov:

 HZ>     Да, могут. И это прекрасно подходит для PC. В случае же embedded
 HZ> при переносе на новую платформу надо все эти вещи внимательно смотреть
 HZ> и оценивать. И, возможно, что-то корректировать. Если вслепую это
 HZ> пихать, то можно получить, согласись, весьма неожиданные результаты.

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

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Даже лошадь Пржевальского может быть собакой Павлова.

LPC2xxx
Mon, 14 Nov 2005 15:03:28 +0300 Alex Mogilnikov wrote to Harry Zhurov:

AM> 14 Nov 05 09:08, Harry Zhurov писал Alex Mogilnikov:

HZ>>     Да, могут. И это прекрасно подходит для PC. В случае же embedded
HZ>> при переносе на новую платформу надо все эти вещи внимательно смотреть
HZ>> и оценивать. И, возможно, что-то корректировать. Если вслепую это
HZ>> пихать, то можно получить, согласись, весьма неожиданные результаты.

AM>     Я считаю, что из того факта, что в проекте существует
AM> платформозависимый драйвер (который, гипотетически, когда и если придется
AM> переходить на другую платформу, может потребоваться переписать),

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

AM> неверно делать вывод, что не существует программирования "на чистом C".

    С этим тезисом я не спорил. Программирование "на чистом С", разумеется
есть. В пределах PC, например. :)

--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
LPC2xxx
Привет Andy!

11 Nov 05 14:18, Andy Mozzhevilov писал Evgeny Kotsuba:

 AM> Hикто же не запрещает. Говорится о потенциальных проблемах при
 AM> использовании union при кроссплатформенности.

    В таком применении union - просто другая запись конструкций типа
(char*)&my_struct.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... В системе возможно бесконечное число процессов - до 256.

LPC2xxx
Привет, Andy !


 11 Nov 05 , 07:00  Andy Mozzhevilov писал к Igor Ulanov:

AM> union
AM> {
AM>     char Buf[10];
AM>     struct {
AM>       unsigned char  addr;
AM>       unsigned int   cmd;
AM>       unsigned char  params[7];
AM>     } pkt;
AM> } rx;

AM> Как ты думаешь, какое значение будет иметь sizeof(rx)?

AM> Hекоторые компиляторы,
AM> правда, поддерживают артибут "packet" для структур, который запрещает
AM> выравнивание внутри структуры, но это уже расширения компилятора,
AM> которого может и не быть.

#pragma pack вроде бы тоже достаточно стандартною или не?

.                                            С уважением, Hикита.
icq:240059686, lj-user:nicka_startcev
... Спаривание электронов под контролем принципа Паули

Re: LPC2xxx
Hello, Nickita A Startcev!
You wrote in conference fido7.ru.embedded to Andy Mozzhevilov on Sat, 12 Nov
2005 00:30:52
+0300:

 NA> #pragma pack вроде бы тоже достаточно стандартною или не?


Не.

dima
http://www.dorlov.no-ip.com


LPC2xxx
Wed Nov 09 2005 14:51, Andy Mozzhevilov wrote to Evgeny Kotsuba:


 AM> Wed Nov 09 2005 10:50, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 EK>>>> Hет ли где чего-нить типа "C-программирование LPC2xxx для чайников"
 EK>>>> или  для начинающих/мигрантов, или "национальные особенности
 EK>>>> программирования  под субж" ?

 AM>>> Уж сколько pаз твеpдили миpy, нет пpогpаммиpования на С для PIC, для
 AM>>> x51,  для AVR, для LPC2000.

 EK>> ты это расскажи авторам кучи книжек с названиями "Программирование на
 EK>> С/C++ под XXX". Правда 95-98%  этого XXX - это Windows в разных видах
 EK>> ;-)

 AM> Ты видел хоть одну подобную книгу для эхотажных платформ?
а я их искал ?
не может не быть, чтоб не было - вот одну уже подсказали

 AM>>> Есть пpогpаммиpование на С (С++) вне зависимости от
 AM>>> платфоpмы, и есть pасшиpения С-компилятоpа для конкpетной платфоpмы.

 EK>> Hе бывает программирования на С (С++) вне зависимости от платформы.

 AM> Бывает.

нет. Это все тот же сферический конь в ваккууме

 EK>> Hу не буду я под DSP писать так же, как под оконный интерфейс, или в
 EK>> драйвере под  писюк - так же как под DSP. Или даже в драйвере под линукс
 EK>> также как в драйвере под ось. И под 8/16 и 32-битные процессоры эхотага
 EK>> тоже буду писать по разному.

 AM> Это уже несколько другой вопрос.

 AM>>> По пеpвой теме есть множество yчебников, а pасшиpения изyчаются по
 AM>>> докyментации на компилятоp.
 AM>>> Конкpтено LPC2000 - это ARM ядpо, компилятоpы под него есть y ARM (ads,
 AM>>> rvds), IAR, Keil, GNU. По pасшиpениям С все pазные в той или иной
 AM>>> степени.

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

 AM> Там всей специфики - на 2-3 страницы, никто ради этого целую книгу писать
 AM> не будет. Ты лучше конкретные вопросы спроси, что тебя смущает _при
 AM> знании Ц_  писать на нем под LPC2000?
знание Ц_ ничего не дает в плане работы с прерываниями или с расчетом времен
задержек и т.п.

 AM> Какой конкретно компилятор ты
 AM> собираешься использовать? Задавай конкретные вопросы, получай конкретные
 AM> ответы.
ну вот тебе конкретный вопрос - нет ли каких подводных камней при
использовании float point арифметики ? А  преобразование int во float и
обратно не много времени занимает ?

Вот тебе другой конкретный вопрос: а почему прерывания не атомарны и как с
этим жыть ? В более дугих платформах пользуют мутексные семафоры, а тут как
жить ?


 AM> Я под LPC пользую компилятор для ARM от IAR - v4.30A
ну вот тебе третий конкретный вопрос  - чем оно лучше/хуже keil'а  и  GNU ?


SY,
EK


LPC2xxx
Wed Nov 09 2005 18:23, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 

 EK> ну вот тебе конкретный вопрос - нет ли каких подводных камней при
 EK> использовании float point арифметики ? А  преобразование int во float и
 EK> обратно не много времени занимает ?

 Hу вот тебе конкретный ответ: если это важно, сделайте свою float
 арифметику на тех же сях.

 EK> Вот тебе другой конкретный вопрос: а почему прерывания не атомарны и как
 EK> с этим жыть ?

 Жыть с этим так: всегда считать, что любые операции неатоммарны.
  
 EK> В более дугих платформах пользуют мутексные семафоры, а тут
 EK> как жить ?

 Определить соответствующий файл с макросами и функциями. При переходе
 на другую платформу переписать несколько дефайнов.

 VLV

 "Зачем стадам дары свободы? Их надо резать или стричь"  (Пушкин)


LPC2xxx
Wed Nov 09 2005 18:34, Vladimir Vassilevsky wrote to Evgeny Kotsuba:


 VV> Wed Nov 09 2005 18:23, Evgeny Kotsuba wrote to Andy Mozzhevilov:

 VV>  

 EK>> ну вот тебе конкретный вопрос - нет ли каких подводных камней при
 EK>> использовании float point арифметики ? А  преобразование int во float и
 EK>> обратно не много времени занимает ?

 VV>  Hу вот тебе конкретный ответ: если это важно, сделайте свою float
 VV>  арифметику на тех же сях.

это не конкретный ответ.
Более того, - это вообще не ответ.
Вот тут с передней парты говорят, что аппаратной поддержки float point
арифметики нет, хотя keil дебугеросимулятор показывает  вполне приличные
времена...

 EK>> Вот тебе другой конкретный вопрос: а почему прерывания не атомарны и как
 EK>> с этим жыть ?

 VV>  Жыть с этим так: всегда считать, что любые операции неатоммарны.
 VV>  
это называется - слил.

 EK>> В более дугих платформах пользуют мутексные семафоры, а тут
 EK>> как жить ?

 VV>  Определить соответствующий файл с макросами и функциями. При переходе
 VV>  на другую платформу переписать несколько дефайнов.

который файл, с какими, (бип), макросами ?
Если я запрещаю прерывание, а оно таки выполняется - то в чем я не могу быть
уверенным, а в чем нет ?

volatile int xxx = 0;

interrupt foo1()
{  
   xxx = 0;
}

int non_interrupt foo2(int z)
{  
   xxx = 2;
   return z/xxx;
}

И как с таким бороться ?

SY,
EK


LPC2xxx
Thu Nov 10 2005 13:13, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

 VV>>  Hу вот тебе конкретный ответ: если это важно, сделайте свою float
 VV>>  арифметику на тех же сях.

 EK> это не конкретный ответ.
 EK> Более того, - это вообще не ответ.
 EK> Вот тут с передней парты говорят, что аппаратной поддержки float point
 EK> арифметики нет,

Для этого достаточно почитать даташиты на ARM7TDMI, чтобы понять, что нет
аппаратной поддержки float.

 EK>>> Вот тебе другой конкретный вопрос: а почему прерывания не атомарны и
 EK>>> как  с этим жыть ?

 VV>>  Жыть с этим так: всегда считать, что любые операции неатоммарны.
 VV>>  

 EK> это называется - слил.

Это называется, спросил то - не понял что.

 EK> который файл, с какими, (бип), макросами ?
 EK> Если я запрещаю прерывание, а оно таки выполняется - то в чем я не могу
 EK> быть уверенным, а в чем нет ?

Что значит запрещаешь прерывания, а оно таки выполняетя?
Если ты запрещаешь прерывание, то оно таки запрещается.

 EK> volatile int xxx = 0;

 EK> interrupt foo1()
 EK> {  
 EK>    xxx = 0;
 EK> }

 EK> int non_interrupt foo2(int z)
 EK> {  
 EK>    xxx = 2;
 EK>    return z/xxx;
 EK> }

 EK> И как с таким бороться ?

Где ты здесь запрещаешь прерывания?

icq 44341220


LPC2xxx
Thu Nov 10 2005 13:13, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

 
 EK>>> ну вот тебе конкретный вопрос - нет ли каких подводных камней при
 EK>>> использовании float point арифметики ? А  преобразование int во float и
 EK>>> обратно не много времени занимает ?
 VV>>  Hу вот тебе конкретный ответ: если это важно, сделайте свою float
 VV>>  арифметику на тех же сях.
 EK> это не конкретный ответ.
 EK> Более того, - это вообще не ответ.

 Мне известно про существование нереентерабельных библиотек, которые
 так сделаны ради эффективности. Иногда это может быть проблемой.
 Какие еще могут быть проблемы с библиотеками?

 
 EK> Вот тут с передней парты говорят, что аппаратной поддержки float point
 EK> арифметики нет, хотя keil дебугеросимулятор показывает  вполне приличные
 EK> времена...

 У дядьки в Киеве уродилась хорошая бузина. И что?

 EK>>> Вот тебе другой конкретный вопрос: а почему прерывания не атомарны и
 EK>>> как  с этим жыть ?
 VV>>  Жыть с этим так: всегда считать, что любые операции неатоммарны.
 EK> это называется - слил.
 
 А ты просто дурак и ламер ленивый.
 
 А как еще сделать?  Какие операции атоммарны, а какие нет - очень
 платформозависимо. Поэтому считаем все операции неатоммарными. Hикаких
 особых трудностей это не вызывает.

 EK>>> В более дугих платформах пользуют мутексные семафоры, а тут
 EK>>> как жить ?

 VV>>  Определить соответствующий файл с макросами и функциями. При переходе
 VV>>  на другую платформу переписать несколько дефайнов.

 EK> который файл, с какими, (бип), макросами ?
 EK> Если я запрещаю прерывание, а оно таки выполняется - то в чем я не могу
 EK> быть уверенным, а в чем нет ?

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

//-------------

HAL.H

 #define DISABLE_INTERRUPT what_the_fuck_it_takes_to_disable_interrupt
 #define ENABLE_INTERRUPT what_the_fuck_it_takes_to_enable_interrupt

//=---------------

 EK> volatile int xxx = 0;
 EK> interrupt foo1()
 EK> {  
 EK>    xxx = 0;
 EK> }
 EK> int non_interrupt foo2(int z)
 EK> {  
 
 DISABLE_INTERRUPT;

 EK>    xxx = 2;
        
        y = z/xxx;
 
 ENABLE_INTERRUPT;

 EK>    return y;
 EK> }
 EK> И как с таким бороться ?

 Такие дела, дядя.
 
 VLV

 "Зачем стадам дары свободы? Их надо резать или стричь"  (Пушкин)


LPC2xxx
Thu Nov 10 2005 17:16, Vladimir Vassilevsky wrote to Evgeny Kotsuba:

 VV>  А ты просто дурак и ламер ленивый.
обычно дураками и ламерами обзываются дураки и ламеры.


 VV>  Пить меньше надо. Тогда если запрещаешь прерывания, они будут
 VV> запрещаться.

ARM-based Microcontroller
SPURIOUS INTERRUPTS
Spurious interrupts are possible to occur in the ARM7TDMI based
microcontroller such as the LPC2114/2124/2212/2214 due to
the asynchronous interrupt handling. The asynchronous character of the
interrupt processing has its roots in the interaction of
the core and the VIC. If the VIC state is changed between the moments when the
core detects an interrupt and the core actually
processes an interrupt, problems may be generated.
Real-life application may experience following scenario:
1) VIC decides there is an IRQ interrupt and sends the IRQ signal to the core.
2) Core latches the IRQ state.
3) Processing continues for a few cycles due to pipelining.
4) Core loads IRQ address from VIC.
Furthermore, It is possible that the VIC state has changed during the step 3.
For example, VIC was modified so that the interrupt
that triggered the sequence starting with step 1) is no longer pending
-interrupt got disabled in the executed code. In this case,
the VIC will not be able to clearly identify the interrupt that generated the
interrupt request, and as a result the VIC will return the
default interrupt VicDefVectAddr (0xFFFF F034).
This potentialy disastrous chain of events can be prevented in two ways:
1. Application code should be set up in a way to prevent the spurious
interrupts to ever happen. Simple guarding of changes to
the VIC may not not be enough, since for example glitches on level sensitive
interrupts can also cause spurious interrupts.
2. VIC default handler should be set up and tested properly.


Details and Case Studies on Spurious Interrupts
This chapter contains details that can be obtained from the official ARM
website (http://www.arm.com ), FAQ section under the
"Technical Support" link: http://www.arm.com/support/faqip/3677.html .
What happens if an interrupt occurs as it is being disabled?

 VV>  Такие дела, дядя.


SY,
EK


Re: LPC2xxx
Hello, Evgeny Kotsuba!
You wrote in conference fido7.ru.embedded to Vladimir Vassilevsky on Thu, 10 Nov
2005 23:33:54 +0300:

 VV>>  А ты просто дурак и ламер ленивый.
 EK> обычно дураками и ламерами обзываются дураки и ламеры.

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

 VV>>  Пить меньше надо. Тогда если запрещаешь прерывания, они
 VV>> будут запрещаться.

 EK> ARM-based Microcontroller
 EK> SPURIOUS INTERRUPTS
 EK> Spurious interrupts are possible to occur in the ARM7TDMI
 EK> based microcontroller such as the LPC2114/2124/2212/2214 due
 EK> to the asynchronous interrupt handling.

Ну и какое это все имеет отношение к запрету прерываний и особенно к
программированию на С? Ты сам-то прочитал тот текст, что запостил?

[Sorry, skipped]


dima
http://www.dorlov.no-ip.com


LPC2xxx
Thu Nov 10 2005 22:33, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

 
 VV>> Пить меньше надо. Тогда если запрещаешь прерывания, они будут
 VV>> запрещаться.

 EK> ARM-based Microcontroller
 EK> SPURIOUS INTERRUPTS
 EK> Spurious interrupts are possible to occur in the ARM7TDMI based
 EK> microcontroller such as the LPC2114/2124/2212/2214 due to
 EK> the asynchronous interrupt handling.

 Hу и какие проблемы?

 Всегда есть способ принудительно сбросить пайплайн или хотя бы
 выполнить пустой код, чтобы прерывание успело запретиться.
 
 
 void Dummy(void)
  {
  static u16 dummy;
  dummy++;
  }


 void DisableInterrupts(void)
  {
  _disable();
  Dummy();
  }

 VLV

 "Зачем стадам дары свободы? Их надо резать или стричь"  (Пушкин)


LPC2xxx
Thu Nov 10 2005 22:33, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

 EK> This potentialy disastrous chain of events can be prevented in two ways:
 EK> 1. Application code should be set up in a way to prevent the spurious
 EK> interrupts to ever happen. Simple guarding of changes to
 EK> the VIC may not not be enough, since for example glitches on level
 EK> sensitive interrupts can also cause spurious interrupts.
 EK> 2. VIC default handler should be set up and tested properly.

Исполнение п.2 вообще практически ничего не меняет в обработчике прерываний,
полностью избавляя от фантомного прерывания. Тем более, что VIC default
handler по ресету устанавливается в 0, а когда в обработчике прерываний в
цикле выгребается очередь адресов isr, то 0 адрес является признаком отсутвия
isr. Так что все само получается без дополнительных проблем.

icq 44341220


LPC2xxx
Thu Nov 10 2005 17:16, Vladimir Vassilevsky wrote to Evgeny Kotsuba:


 VV> Thu Nov 10 2005 13:13, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

 VV>  

 EK>>>> ну вот тебе конкретный вопрос - нет ли каких подводных камней при
 EK>>>> использовании float point арифметики ? А  преобразование int во float
 EK>>>> и  обратно не много времени занимает ?
 VV>>>  Hу вот тебе конкретный ответ: если это важно, сделайте свою float
 VV>>>  арифметику на тех же сях.
 EK>> это не конкретный ответ.
 EK>> Более того, - это вообще не ответ.

 VV>  Мне известно про существование нереентерабельных библиотек, которые
 VV>  так сделаны ради эффективности. Иногда это может быть проблемой.
 VV>  Какие еще могут быть проблемы с библиотеками?

чего-то я в большом смущении и непонятках:
float s,x,y;
int i,l,k,m;

0.003   for(i=0;i<100; i++)
0.667   {  m += l;
1.887      l = l * k;
1.993   }
0.003   for(i=0; i<100; i++)
5.000   { s += x;
3.000     x = x * y;
1.993   }
т.е. float point где-то раза в 3 медленнее челочисленной арифметики... как
можно написать самому float арифметику да еще и на сях и уложится в три
оператора ?


 EK>> Вот тут с передней парты говорят, что аппаратной поддержки float point
 EK>> арифметики нет, хотя keil дебугеросимулятор показывает  вполне приличные
 EK>> времена...

 VV>  У дядьки в Киеве уродилась хорошая бузина. И что?

что, дебугосимулятор не умеет считать времена ? И в keil'е программисты все
уроды ?

 VV> Мне известно про существование нереентерабельных библиотек, которые
 VV>  так сделаны ради эффективности. Иногда это может быть проблемой.
 VV>  Какие еще могут быть проблемы с библиотеками?

Да незнаю я! Клещами надо выдирать - эти нереентабельные библиотеки у какого
из компиляторов ?


SY,
EK


LPC2xxx
Thu Nov 10 2005 23:30, Evgeny Kotsuba wrote to Vladimir Vassilevsky:

 EK> т.е. float point где-то раза в 3 медленнее челочисленной арифметики...

 Вполне может быть. BTW, может быть и наоборот.
 Вопрос в том, насколько это критично.    

 EK> как можно написать самому float арифметику да еще и на сях и уложится в
 EK> три оператора ?

 Cделать свой трехбайтовый или двухбайтовый float.
 Переписать узкие места с жестокой оптимизацией через таблицы.
 Да мало ли еще способов.

 EK> что, дебугосимулятор не умеет считать времена ?

 Какой-сякой дебагер? Светодиод и осциллограф.

 EK> И в keil'е программисты все уроды ?

 Программисты вообще все уроды.

 VV>> существование нереентерабельных библиотек, которые
 VV>> так сделаны ради эффективности.
 EK> Да незнаю я! Клещами надо выдирать - эти нереентабельные библиотеки у
 EK> какого из компиляторов ?

 Hасчет subj не знаю, а нереентерабельные библиотеки замечены в 6808,
 в пикоманстве, в ADSP21xx.

 VLV

 "Зачем стадам дары свободы? Их надо резать или стричь"  (Пушкин)


LPC2xxx
Hi Vladimir, hope you are having a nice day!


11 Hоя 05, Vladimir Vassilevsky wrote to Evgeny Kotsuba:

 VV>>> существование нереентерабельных библиотек, которые
 VV>>> так сделаны ради эффективности.
 EK>> Да незнаю я! Клещами надо выдирать - эти нереентабельные
 EK>> библиотеки у какого из компиляторов ?
 VV>  Hасчет subj не знаю, а нереентерабельные библиотеки замечены в 6808,
 VV>  в пикоманстве, в ADSP21xx.

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

WBR,
    AVB


LPC2xxx
Fri Nov 11 2005 08:54, Alexey V Bugrov wrote to Vladimir Vassilevsky:

 VV>>  Hасчет subj не знаю, а нереентерабельные библиотеки замечены в 6808,
 VV>>  в пикоманстве, в ADSP21xx.

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

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

 VLV

 "Зачем стадам дары свободы? Их надо резать или стричь"  (Пушкин)


Site Timeline