Почему точка входа в BIOS начинается с инструкции WBINVD?
Я немного изменил этот параметр teaherList, потому что это не действительный объект. Вы можете попробовать что-то вроде этого, результирующий массив будет таким [{teacherID1: teacherName1}, {teacherID2: teacherName2}].
var teaherList = [
{teacherID:1,teacherName:"john"},
{teacherID:2,teacherName:"joe"},
{teacherID:3,teacherName:"jill"},
{teacherID:1,teacherName:"john"},
{teacherID:2,teacherName:"joe"},
{teacherID:3,teacherName:"jill"},
{teacherID:1,teacherName:"john"},
{teacherID:2,teacherName:"joe"},
{teacherID:3,teacherName:"jill"},
]
var result = teaherList.reduce(function(acc, cV) {
if(!acc[cV.teacherName]) {
acc[cV.teacherName]= {teacherID: cV.teacherID,
teacherName: cV.teacherName,
count: 1};
} else {
acc[cV.teacherName].count++;
}
return acc;
}, {});
console.log(result);Надеюсь, это поможет.
1 ответ
Хотя об этом трудно рассуждать, помните, что загрузка mov al, byte es:[0xfff0] не считывает из первой инструкции BIOS, даже если es установлен на 0xf000.
Первая инструкция считывается из 0xfffffff0, при сбросе PCH, вероятно, будет также псевдонимом 0xf0000-0xfffff - 0xffff0000-0xffffffff, поэтому при загрузке BSP он выполнит код, который вы сбросили.
[ 1117] IIRC, AP не загружаются, если явно не проснуться.
Затем BSP продолжит инициализацию HW (исходя из дампа).
В какой-то момент он установит карту атрибутов для 0xf0000-0xfffff для управления чтением и записью (или просто записью, а затем чтением) в память.
Конечным результатом является то, что когда процессор (поток HW) загружается, он будет выполнять код с флэш-памяти до тех пор, пока не выполнит дальний переход.
В этот момент база cs правильно вычисляется в соответствии с правилами реального режима (почти как в нереальном режиме), и инструкция будет извлечена из 0xf0000-0xfffff (то есть из ОЗУ).
Все это в то время как значение сегмента cs фактически не изменилось.
BSP в какой-то момент начнет свою процедуру инициализации мультипроцессора, где он транслирует каждому (включая его самого) INIT-SIPI-SIPI, который приведет к сну для AP и ljmp 0xf000:0xfff0 для BSP.
] [+1122] Хитрость в том, что цель перехода, 0xf000:0xfff0, не совпадает с адресом шины инструкции wbinvd.
Там может быть что-то еще, возможно, другая процедура инициализации.
В конце инициализации BIOS может просто сбросить атрибуты 0xf0000-0xfffff для сброса на флэш-память (поэтому возможен программный сброс), предотвращая (не преднамеренно) сброс промежуточного кода.
Это не очень эффективно, но BIOS обычно не являются шедеврами кода.
У меня недостаточно элементов, чтобы быть уверенным в том, что происходит, я хочу сказать, что ljmp 0xf000:0xfff0 и mov al, byte es:[0xfff0] не должны читать из того же региона, в котором они находятся. [+1136] [1 124] [1 124] С учетом этого все ставки отменены.
Только правильный обратный инжиниринг скажет.
Что касается wbinvd, я предположил в комментарии, что это может быть связано со средством «горячей» загрузки, а Питер Кордес предположил, что это может быть конкретно связано с кэшем как ОЗУ.
Это имеет смысл, я думаю, никогда не будет уверен, хотя.
Это также может быть случай культа груза, когда программист посчитал, что инструкция необходима на основе слухов. [+1135]