однако, после того как на 2040 запустили дум и вот недавно ещё редалёрт на 2350, эмуляция всяких 4/8 битных древностей, типа спектрума целиком в pi pico, выглядит уже не столь впечатляюще.
поскольку тот же Python больше не во младенческом возрасте
наброшу,
Сугубо имхо, но использовать пробел в качестве элемента синтаксиса языка это гораздо большая упоротость чем все вместевзятые: индексация с 1, глобальные переменные, begin/end и т.п.
В качестве встраиваемого скриптового языка в ядро (linux/netbsd) насколько знаю питон или js, пусть и подрезанные, запихать никто даже особо не пытался, а lunatik как-то живёт.
Чуть менее упоротым синтаксисом (тикль вроде заметно старше)? Даже несмотря на все те вещи (~=, then, begin, end, continue) которые в Lua можно было бы сделать и более похожими на С.
Метатаблицами, которые опять же, хоть и несколько неочевидно на первый взгляд, но элегантно позволяют делать много чего.
Довольно аккуратным С api, но тут про tcl мало чего знаю, так что сложно сравнивать.
В Математике индексация с 1 не потому что 0 уже был занят типом, скорее в пустое место между первым (1) и последним (-1) можно было что-нибудь воткнуть, размер, например, но путаницы было бы больше при случайном обращении к [[0]] по ошибке.
Осталось только понять зачем это "смещение" от 0 по адресу пытаются использовать для индексации в языках, в которых впринципе такой сущности как "указатель" на какой-то адрес в памяти и соответствующие манипуляции с ними и памятью отсутсвуют как класс.
В Си и языках которые допускают прямую работу с памятью и вообще можно inline assemby - пожалуйста. В верилоге индексация как в паскале хоть и произвольная, но считать биты в байте с единицы никто не будет, т.к. 2^0=1,
wire [7:4] w1; wire [3:6] w2;
а тот кто массивы 0 индексируемых бит будет объединять в массивы 1 индексированных "слов" видно что очень не любит людей которым это потом после него разгребать придётся :)
Есть достаточно 1indexing языков (Julia, Wolfram Mathematica, R, Matlab), где нету реализации массивов как тупо указателя на первый :) элемент и вообще указателей как таковых и соответственно связанной с ними адресной арифметики (сишный вывернутый мехом внутрь index[array] == array[index], и количество ошибок связанных с array[N] для адресации последнего элемента). И эти костыли, которые экономили лишний байт в допотопных языках когда память измерялась в килобайтах и имеющие смысл когда язык недалеко от железа и хотя бы умеет в inline assembly, теперь из-за якобы "обратной совместимости" зачем-то тащат дальше, например в какие-нибудь js и python, труъ "программисты" которых понятия не имеют откуда вообще взялась индексация с 0, а если вдруг с 1 то это ужас-ужас-ужас.
Я вроде достаточно написал кода для взаимодействия Lua<->C, там где индексация вообще получается "смешанной" с разных сторон и это как-то не особо напрягало.
требует больших объемов закрытого кода, из-за чего его практически невозможно реализовать самостоятельно, даже если у вас есть все необходимые спецификации
А они вообще есть? Особенно на всякие интловские ME и амдшные PSP.
Ну то есть coreboot с блобами, а у всяких libre/gnuboot и открытых seabios в списке поддерживаемого оборудования самое новое лет 15 назад с производства снято.
И baremetalный "hello world" (без uefi), чтобы прямо из spi flash, невозможен сегодня на современном х64 железе впринципе? Для какой-нибудь более специфичной железки у которой аппаратная конфигурация заведомо определена раз и навсегда, распаяна и меняться никода не будет.
Вы там в одном варианте на 10ГэВ замахнулись, градиент ускорения в сверхпроводящих резонаторах ~30МэВ/м, длину "компактного" ускорителя можете прикинуть сами.
Пучок "короткий" только для ТГц источников, где длина волны под сотню мкм.
А для более коротких волн в длинном пучке электронов на каждый излучающий электрон с какой-то фазой всегда найдётся ещё один такой же, который будет ровно на пол периода излучения отставать и излучать соответственно в противофазе. В результате такого "некогерентного" излучения по статистике складывается поле только от корня из количества электронов.
Чтобы они излучали когерентно надо электронный пучок вдоль длины промодулировать по плотности с периодом излучаемой длины волны чтобы они все излучали в фазе.
Так обычно само получается если пучок достаточно аккуратный, а ондулятор длинный (~1000 периодов), тогда электромагнитные поля от излучения самого пучка добавляют/отнимают у электронов энергию, в результате он сам себя модулирует по интенсивности и вместо корня из количества электронов в складываются уже просто количество электронов без корня, это в поле, по мощности получается пропорционально количеству электронов в квадрате вместо просто количества электронов в пучке. И при зарядах пучка ~наноКулона т.е. количестве электронов ~1e7 разница заметная.
Но резонаторы не делают потому что рентген с длиной волны в десяток кЭв не очень хорошо отражается, для него как бы всё почти прозрачно, разве что только под совсем небольшими углами.
Вместо резонаторов и накопления "излучения" для лучшего его взаимодейтвия с пучком в лазерах на свободных электронах делают seeding, то есть модуляцию оптическим лазером, чтобы потом по этим предварительным "зарубкам" на пучке, пусть и на в 1000 раз большей длине волны, процесс потом SASE начался увереннее.
Чтобы получился "лазер" электронный пучок должен быть короче излучаемой длины волны (что как-то работает для ТГц диапазона, но не для 0.01–10 нм) либо очень длинный ондулятор для возникновения SASE и "микробанчинга" пучка собственным излучением.
Два кадра надо снимать, со включенной дополнительной подсветкой и с выключенной, и брать разницу, чтобы от внешнего освещения меньше зависеть. Но к готовой USB камере немного сложнее синхронизацию приделать, непосредственно к сенсору надо лезть за vsync.
В современных биосах внутри x86 процессора уже довольно давно сидит ещё какой-нибудь ARM-A5, который стартует первым, и имея доступ ко всему сначала инициализирует всё что надо, включая память, складывает туда что надо и передаёт управление х86 без всяких CAR.
А вот что этот арм там потом может делать - отдельный очень интересный вопрос...
Эти клоны из чего только не лепят, у меня такой из 8051 силабса, но хотя бы с нормальным буфером, который питание от прошиваемого устройства берёт.
Ещё как вариант можно взять ft[2]232h, с драйверами от марсохода его квартус за бластер считать будет, а сменой id в еепроме им же и xilinx и lattice шить можно.
да,
однако, после того как на 2040 запустили дум и вот недавно ещё редалёрт на 2350, эмуляция всяких 4/8 битных древностей, типа спектрума целиком в pi pico, выглядит уже не столь впечатляюще.
наброшу,
Сугубо имхо, но использовать пробел в качестве элемента синтаксиса языка это гораздо большая упоротость чем все вместевзятые: индексация с 1, глобальные переменные, begin/end и т.п.
В качестве встраиваемого скриптового языка в ядро (linux/netbsd) насколько знаю питон или js, пусть и подрезанные, запихать никто даже особо не пытался, а lunatik как-то живёт.
Чуть менее упоротым синтаксисом (тикль вроде заметно старше)? Даже несмотря на все те вещи (~=, then, begin, end, continue) которые в Lua можно было бы сделать и более похожими на С.
Метатаблицами, которые опять же, хоть и несколько неочевидно на первый взгляд, но элегантно позволяют делать много чего.
Довольно аккуратным С api, но тут про tcl мало чего знаю, так что сложно сравнивать.
может не использовать целые числа в качестве названия членов объекта?
Потом кармы в виде сотни тысяч строк яваскрита не боитесь? это выглядит имхо даже хуже.
з.ы чтобы совсем не скучно было надо просто собрать саму Lua в wasm :)
В Математике индексация с 1 не потому что 0 уже был занят типом, скорее в пустое место между первым (1) и последним (-1) можно было что-нибудь воткнуть, размер, например, но путаницы было бы больше при случайном обращении к [[0]] по ошибке.
Осталось только понять зачем это "смещение" от 0 по адресу пытаются использовать для индексации в языках, в которых впринципе такой сущности как "указатель" на какой-то адрес в памяти и соответствующие манипуляции с ними и памятью отсутсвуют как класс.
В Си и языках которые допускают прямую работу с памятью и вообще можно inline assemby - пожалуйста. В верилоге индексация как в паскале хоть и произвольная, но считать биты в байте с единицы никто не будет, т.к. 2^0=1,
wire [7:4] w1;
wire [3:6] w2;
а тот кто массивы 0 индексируемых бит будет объединять в массивы 1 индексированных "слов" видно что очень не любит людей которым это потом после него разгребать придётся :)
там рефлексию человеческую до сих пор не завезли, поэтому через внешние генераторы типа swig или tolua++, которые из хедеров генерят обёртки - вполне.
Есть достаточно 1indexing языков (Julia, Wolfram Mathematica, R, Matlab), где нету реализации массивов как тупо указателя на первый :) элемент и вообще указателей как таковых и соответственно связанной с ними адресной арифметики (сишный вывернутый мехом внутрь index[array] == array[index], и количество ошибок связанных с array[N] для адресации последнего элемента). И эти костыли, которые экономили лишний байт в допотопных языках когда память измерялась в килобайтах и имеющие смысл когда язык недалеко от железа и хотя бы умеет в inline assembly, теперь из-за якобы "обратной совместимости" зачем-то тащат дальше, например в какие-нибудь js и python, труъ "программисты" которых понятия не имеют откуда вообще взялась индексация с 0, а если вдруг с 1 то это ужас-ужас-ужас.
Я вроде достаточно написал кода для взаимодействия Lua<->C, там где индексация вообще получается "смешанной" с разных сторон и это как-то не особо напрягало.
sandustry, пока ещё демка, но забавная, factorio+noita :)
требует больших объемов закрытого кода, из-за чего его практически невозможно реализовать самостоятельно, даже если у вас есть все необходимые спецификацииА они вообще есть? Особенно на всякие интловские ME и амдшные PSP.
Ну то есть coreboot с блобами, а у всяких libre/gnuboot и открытых seabios в списке поддерживаемого оборудования самое новое лет 15 назад с производства снято.
И baremetalный "hello world" (без uefi), чтобы прямо из spi flash, невозможен сегодня на современном х64 железе впринципе? Для какой-нибудь более специфичной железки у которой аппаратная конфигурация заведомо определена раз и навсегда, распаяна и меняться никода не будет.
Вы там в одном варианте на 10ГэВ замахнулись, градиент ускорения в сверхпроводящих резонаторах ~30МэВ/м, длину "компактного" ускорителя можете прикинуть сами.
https://www.xfel.eu/facility/accelerator/index_eng.html
Пучок "короткий" только для ТГц источников, где длина волны под сотню мкм.
А для более коротких волн в длинном пучке электронов на каждый излучающий электрон с какой-то фазой всегда найдётся ещё один такой же, который будет ровно на пол периода излучения отставать и излучать соответственно в противофазе. В результате такого "некогерентного" излучения по статистике складывается поле только от корня из количества электронов.
Чтобы они излучали когерентно надо электронный пучок вдоль длины промодулировать по плотности с периодом излучаемой длины волны чтобы они все излучали в фазе.
Так обычно само получается если пучок достаточно аккуратный, а ондулятор длинный (~1000 периодов), тогда электромагнитные поля от излучения самого пучка добавляют/отнимают у электронов энергию, в результате он сам себя модулирует по интенсивности и вместо корня из количества электронов в складываются уже просто количество электронов без корня, это в поле, по мощности получается пропорционально количеству электронов в квадрате вместо просто количества электронов в пучке. И при зарядах пучка ~наноКулона т.е. количестве электронов ~1e7 разница заметная.
Но резонаторы не делают потому что рентген с длиной волны в десяток кЭв не очень хорошо отражается, для него как бы всё почти прозрачно, разве что только под совсем небольшими углами.
Вместо резонаторов и накопления "излучения" для лучшего его взаимодейтвия с пучком в лазерах на свободных электронах делают seeding, то есть модуляцию оптическим лазером, чтобы потом по этим предварительным "зарубкам" на пучке, пусть и на в 1000 раз большей длине волны, процесс потом SASE начался увереннее.
Есть всякие проекты с резонаторами https://arxiv.org/abs/1903.09317 но насколько знаю никто так и не реализовал нормально.
потому что нужный адрес это &_text_start, а не сам _text_start.
Картинки перерисуйте, электроны отклоняются не вдоль магнитного поля, а поперёк.
1Т поля при 10мм периоде без сверхпроводимости получить не реально.[https://iopscience.iop.org/article/10.1088/1361-6668/acc1a8]
Ондуляторы обычно либо сверхпроводящие, либо из постоянных магнитов, "теплые" электромагнитные почти никто не делает, за редким исключением больших периодов и не очень больших полей (например источники ТГц излучения на ускорителях с большой энергией). Ондулятор с переменным периодом: https://pubs.aip.org/aip/acp/article/2054/1/030024/1023236/Variable-period-undulator-with-tunable
Чтобы получился "лазер" электронный пучок должен быть короче излучаемой длины волны (что как-то работает для ТГц диапазона, но не для 0.01–10 нм) либо очень длинный ондулятор для возникновения SASE и "микробанчинга" пучка собственным излучением.
Встроенная физика там только F7 и >lpqf144
Но у китайцев есть ch32v305, даже в tsop20 корпусе
Два кадра надо снимать, со включенной дополнительной подсветкой и с выключенной, и брать разницу, чтобы от внешнего освещения меньше зависеть. Но к готовой USB камере немного сложнее синхронизацию приделать, непосредственно к сенсору надо лезть за vsync.
В современных биосах внутри x86 процессора уже довольно давно сидит ещё какой-нибудь ARM-A5, который стартует первым, и имея доступ ко всему сначала инициализирует всё что надо, включая память, складывает туда что надо и передаёт управление х86 без всяких CAR.
А вот что этот арм там потом может делать - отдельный очень интересный вопрос...
Эти клоны из чего только не лепят, у меня такой из 8051 силабса, но хотя бы с нормальным буфером, который питание от прошиваемого устройства берёт.
Ещё как вариант можно взять ft[2]232h, с драйверами от марсохода его квартус за бластер считать будет, а сменой id в еепроме им же и xilinx и lattice шить можно.
i5A-905 ещё красивее выглядит