Fast System Call

Thu Mar 08, 2007 4:49 pm

Для тестов использовал обновленную программу от Ghost. Кстати, обнаружил некоторую странность: начиная с какой-то ревизии (и в официальном и во flat-kernel) на доске отладки во вкладке USER есть надписи, типа "cess - done", иногда просто буква "e", иногда "New process: loadind" (в зависимости от того, где запускаю). Так и должно быть или это глюк?

Thu Mar 08, 2007 4:57 pm

Heavyiron

Это глюк. Кто-то менял код доски отладки, ту часть что в ядре.

Thu Mar 08, 2007 5:08 pm

Не с fdo ли это связано?
Новые тесты с новой ревизией #400 на Sempron 2500+ (K7):
880B78B -> SYSENTER
9E0104C -> SYSCALL
DE18A36 -> Interrupt

Thu Mar 08, 2007 5:16 pm

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

На SYSCALL я тоже возлагал бОльшие надежды (кстати в VMWare он быстрее SYSENTER, но это виртуальная машина...), тесты это не подтвердили. Возможно есть ошибки в реализации, или это просто особенность ядра Thoroughbred, нужно думать.
Тест явно проверяет поддержку механизмов быстрых вызовов, и если их нет просто пишет unsupported, поэтому из-за syscall тест не мог падать.
С технологией EM64T у камней Intel появились инструкции SYSCALL/SYSRET, но : Syscall/sysret is supported only in 64-bit mode (not in compatibility mode).
Доска просто пытается фильтровать сообшения, и начинаюшиеся с "K:" выводит во вклядку ядра, видимо это у неё не всегда получается, но это не критично.

P.S. ядро #400 работает нормально.
P.P.S. есть мысль что AMD Barton 2500+ или AMD K8 3000+ (реально оба тоже на 1800Mhz) будут выполнять тест за ещё меньшее количество тактов.

Thu Mar 08, 2007 5:22 pm

Тогда ждем тестов от Lrz и Mario79

. Кстати, интересно, как с этим дела у Core (mike.dld)

Thu Mar 08, 2007 6:25 pm

Ghost

По АМДшным докам на syscal должно уходить примерно в четыре раза меньше тактов чем на вызов через шлюз.

Heavyiron

Проверь последнее ядро. Глючит или нет. Чем больше разных тестов тем быстрее оно заработает. Кстати у большинства тестеров АМД. Если баги связаны с процессором то мне на Интеле их просто не найти.

Thu Mar 08, 2007 6:33 pm

последние тесты и были с последним ядром - работает нормально без драйверов, однако mike.dld заметил, что англоязычный вариант не компилится...

Thu Mar 08, 2007 6:46 pm

Проверил на своём Core2Duo E6400 2.13@3.2 GHz:

Code: Select all

Please wait
000000000D82A9A8 <- Fast call (SYSENTER)
unsupported      <- Fast call (SYSCALL)
0000000020EC5FE8 <- Interrupt
Alive!

Thu Mar 08, 2007 9:18 pm

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

Mon Mar 12, 2007 2:20 pm

Ноут: PIII 900 Coppermine
Please wait
00000000094f8ABF <- Fast call (SYSENTER)
unsupported <- Fast call (SYSCALL)
0000000012AF614F <- Interrupt
Alive!
AMD 64 ATHLON (3000)
Please wait
000000009DFEE82 <- Fast call (SYSENTER)
00000000B8FF3D0 <- Fast call (SYSCALL)
00000000FDFDC6C <- Interrupt
Alive!

На Athlon Barton 2500 ОС не запустилась.

Mon Mar 12, 2007 7:58 pm

Исправил интерфейс, теперь много поточные программы работают нормально, но вызовы стали медленнее в связи с накладными расходами ), но надеюсь в скором времени улучшить код. По этой причине не выкладываю код на svn, изменённые файлы и собранное ядро можно взять здесь : http://iam.gorodok.net/fc_ker.zip (тут же пересобранный mgb), основанно на #414. Теперь вызовы выглядят так:

Code: Select all

	push	ebp
	mov	ebp, esp
	push	..ret_point
	sysenter
 ..ret_point:
	pop	edx
	pop	ecx

Для sysenter, и так для syscall:

Code: Select all

	push	ecx
	syscall
	pop	ecx

Разработчикам программ советую использывать макрос mcall из файла macros.inc (от mike.dld) в составе fast_call_test, это избавит вас от необходимости в ручную писать громоздкий код вызова (который ещё не устоялся), и даст возможность легко пересобирать программы под любые типы вызовов.
Вот пример (это пример а не рабочая программа):

Code: Select all

include 'macros.inc'
MEOS_APP_START
CODE
  mcall  1
  __CPU_type equ p6
  mcall  2
  __CPU_type equ k6
  mcall  3
  __CPU_type equ p5
  mcall  4
DATA
UDATA
MEOS_APP_END

В этом примере функция 1 и 4 вызовится через прерывания, 2 - через sysenter, 3 - через syscall. Хорошим примером программы использующей mcall является tinypad, поэтому его можно без особых усилий пересобрать для быстрых вызовов, для этого в файле macros.inc из исходников tinypad`а нужно заменить макрос mcall на mcall из fast_call_test, а в файле tinypad.asm после строчки "include 'macros.inc'" добавить строку __CPU_type equ p6. При переделки готовых программ, можно просто заменить вызовы int 0x40 на mcall.

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

Mon Mar 12, 2007 10:24 pm

http://iam.gorodok.net/fc_ker.zip
AMD 64 ATHLON (3000)

Первый раз:
Please wait
00000000С365513 <- Fast call (SYSENTER)
00000000B5В431С <- Fast call (SYSCALL)
00000000FDC6FCC <- Interrupt

Второй раз:
Please wait
00000000C36F20A<- Fast call (SYSENTER)
00000000B5F6A77 <- Fast call (SYSCALL)
00000000FDE0F19 <- Interrupt

но вызовы стали медленнее в связи с накладными расходами

Неслабые накладные расходы, если сравнить с результатами которые выложил <Lrz>...

Меня мучает вопрос: что будет раньше яйцо или курица, то есть плоское ядро или быстрые вызовы?

P.S. На Cyrix не смог проверить, потому что COM мышь не пашет, хотя со стандартным ядром 412 ревизии пашет.

Mon Mar 12, 2007 11:13 pm

Мдя, AMD K7 в плане скорости вызовов рулит

Mario79
Быстрые вызовы уже есть в стандартном ядре, а плоское ядро все еще в разработке, так что яйцо, видимо, первично

Меня мучает другой вопрос: были ли в cyrix быстрые вызовы, и если нет, то что будет с поддержкой таких компов? Придется выпускать еще один дистрибутив для старых процессоров?

Tue Mar 13, 2007 12:37 am

Mario79
Если мышь сидит на COM1 то попробуй переключить её на СОМ2.

Tue Mar 13, 2007 8:00 am

Serge
А что случилось с COM1?

Fast System Call

Who is online