На самом деле, нет. Фотошаблоны обычно рисуют хотя бы на shaped-beam литографах, которые светят прямоугольниками, треугольниками и т.п., или даже на cell-projection, которые проецируют какие-то более сложные примитивы. Только так можно достичь разумного времени экспозиции. Эта же машина имеет гауссов пучок и для этого не подходит - ей как минимум не хватит стабильности отрисовать шаблон целиком. Такие системы нужны для несколько другой работы - исследования, отрисовка затворов HEMT транзисторов в MMIC, +- интегральная фотоника и т.п.
PS: есть у нас именно такая машина (cabl-9000) - мягко говоря, очень не очень :D
90 нм на Микроне было. Мы делали там проект на HCMOS10 - yield не то, чтобы фантастический, но все было более-менее. Выпускается ли что-то по этому процессу сейчас - мне не известно. Как минимум, подозреваю, что есть существенные проблемы с изготовлением фотошаблонов.
В каком-то смысле это так, потому что степперы, в отличие от CAD не качаются из интернета и не размножаются так легко. Но работать без суппорта и на устаревших версиях - такое себе удовольствие :D
Эти утверждения обычно относятся все-таки не к температуре пучка, а к температуре кварк-глюонной плазмы, которая с почти любой практической точки зрения термодинамически равновесна.
В порядке бреда - возможно, в процессе синтеза PrPc он попадает в метастабильное состояние с очень большим временем жизни, потому что "печатается" рибосомой последовательно и выгодная конформация начала белка отличается от выгодной конформации ее же в полностью собранном белке?
Но я не настоящий сварщик, поэтому это всего лишь предположение :)
Единственный (известный мне) способ сообщить компилятору, что сущность объявлена в другом TU - это extern. Лайфтайм такого объекта будет начинаться со старта программы.
Пожалуй, если объявить все объекты такого типа (скажем, регистры устройства) как extern, а потом связать их линкером, то все будет корректно. Безусловно, это очень удобный метод. Особенно подходит для всяких динамических сущностей и перемещаемых (например, с помощью MMU) объектов :D
А здесь речь не о том, что происходит доступ к объекту, который с точки зрения компилятора не вызывает сайд-эффектов, а о том, что объекта никакого нет. Поэтому и доступа никакого быть не может.
Undefined behaviour с точки зрения компилятора целиком - это ситуация, когда нет никаких ограничений на действия генерируемого кода.
После того, как код сгенерирован, его поведение полностью определено, по крайней мере у всех известных мне процессоров общего назначения.
Стандарт не говорит о том, код с каким поведением должен быть сгенерирован при попытке сделать ваше *((*volatile int)0x3) = 1. Большинство современных компиляторов сгенерируют то, что вы ожидаете. От этого этот код не становится валидным и никаких гарантий, что так будет всегда нет.
Видите ли в чем тут дело. C++ - это такой язык, на котором не все синтаксически корректные программы являются валидными. Это, в свою очередь означает, что программа может компилироваться, запускаться и делать что-то похожее на то, что ожидается, но при этом, фактически не быть программой на C++.
STM HAL именно такой. Это не C++ библиотека, а библиотека, написанная на конкретном диалекте, предоставляемом определенным диапазоном версий g++-arm. Работает? Ну да. Потому что обычно собирается в стерильной среде строго определенным компилятором.
Но крайне не завидую, если по какой то причине придется переползать на другой компилятор или будущий стандарт.
Ага, и потом обычное дело - получить набор забавных спецэффектов при попытке запустить код, откомпилированный с -O3 вместо -O0, на котором все вроде как работало :D
Лично мне никогда не приходилось писать freestanding код на C++ (а необходимость что-то скастить таким образом может возникнуть только во freestanding или драйвере, на мой взгляд), но, насколько я помню стандарт, reinterpret_cast is implementation defined, но не является ub при касте инта к указателю на какой-нибудь простой тип.
И вроде даже при касте к сложному объекту, если с точки зрения с++ abstract machine этот объект валиден (это, скорее всего, потребует правок в компиляторе, но стандарт это явно не запрещает).
Вроде как проблему с implementation defined и убеждением абстрактной машины должен решать std::start_lifetime_as, но тут я повторюсь, что я не специалист.
Даже в C можно наесться при написании большого freestanding проекта, на C++ это, наверное, совсем весело.
Нет, к атомарности это не имеет никакого отношения. Это работает только тогда, когда x+c вызывает какой-то сайд-эффект. Сложение интегральных типов никаких сайд-эффектов не порождает.
Под спойлером пример - можете запустить и проверить
Данная программа не является программой на C++, так как содержит в себе undefined behavior.
const_cast makes it possible to form a reference or pointer to non-const type that is actually referring to a const object or a reference or pointer to non-volatile type that is actually referring to a volatile object. Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior.
Тут надо смотреть, во что оно скомпилируется. Если компилировать под 8086 без оптимизаций, например, то я полагаю, с+=1 перейдет в INC с, а c=c+1 - сложит и присвоит через SUM и MOV.
Тут не надо ничего смотреть кроме стандарта. Для интегральных типов это одно и то же. Как при этом ведет себя какой-либо компилятор - дело десятое. Тем более, что современный clang, что gcc сгенерируют один и тот же код с любым бэкэндом даже с -O0
Во-первых, их так и так надо резать, и пластиковые чипы тоже не ножницами вырезаются. Во-вторых, резать можно плазмохимическим травлением, что на таких объемах будет дешево.
Если резать дисковой пилой, то надо считать экономику, но по ощущениям будет меньше $100 (порядка 5 часов работы пилы и существенно меньше одного диска стоимостью ~$30-40).
Направление, безусловно, интересное, но с экономическим обоснованием что-то не вяжется.
Во-первых, у этого FlexiCore крайне низкая плотность. Для сравнения 65nm CMOS обеспечивает плотность порядка 800 Квентилей/мм^2, то есть их ядро будет занимать площадь 0.0025 мм^2. Понятно, что в таком случае доминирующую площадь будут занимать контактные площадки.
Во-вторых, стоимость пустой 300 мм пластины меньше $100, а "испеченной" по 65нм - - около $1800-$2000. С учетом потерь на выход годных порядка 5% (это номинальная величина для столь взрослого техпроцесса для чипов такой малой площади), предположим, что $2000. Таким образом, стоимость пластины для такого процесса - это 5% общей стоимости.
Пусть конечное устройство имеет размер 0.5x0.5 мм, что вполне достаточно для того, чтобы иметь такое ядро и десяток контактных площадок. С учетом скрайб-линий, чипов с пластины получается примерно 200К. Таким образом, стоимость исходной пластины - 0.05 цента, стоимость процесса - 0.95 цента. То есть, как бы тоже более-менее попадает в границу 1 цента.
Насколько я понимаю, этот MPW запуск был сделан на GF по тому же техпроцессу, который должен был ставиться на этом оборудовании. По крайней мере, когда мне в нем предлагали поучаствовать, руководство фаба утверждало именно это.
Боюсь, что не разобрались-то именно вы и автор этого треда.
Вообще, просто какое-то вязкое ощущение ужаса возникает в сознании, когда понимаешь, что такой же уровень компетентности распространен не только среди людей, которые кричат в интернетах, что наконец-то открылись сказочные возможности импортозамещения и мы сейчас все рванем вперед, но и среди людей, непосредственно отвечающих за это самое импортозамещение.
Микроархитектуры firestorm и icestorm, используемые в M1 - это внутренняя разработка Apple, так что нет, код не покупной. Безусловно, это никак не отменяет того факта, что даже если процессорные ядра покупные (а вообще в современных soc процессорные ядра - далеко не доминирующие ip по стоимости), кристаллы все равно разработаны тем, кем они разработаны. Интеграция, верификация и физдизайн - это тоже не самый простой процесс.
На самом деле, нет. Фотошаблоны обычно рисуют хотя бы на shaped-beam литографах, которые светят прямоугольниками, треугольниками и т.п., или даже на cell-projection, которые проецируют какие-то более сложные примитивы. Только так можно достичь разумного времени экспозиции. Эта же машина имеет гауссов пучок и для этого не подходит - ей как минимум не хватит стабильности отрисовать шаблон целиком. Такие системы нужны для несколько другой работы - исследования, отрисовка затворов HEMT транзисторов в MMIC, +- интегральная фотоника и т.п.
PS: есть у нас именно такая машина (cabl-9000) - мягко говоря, очень не очень :D
90 нм на Микроне было. Мы делали там проект на HCMOS10 - yield не то, чтобы фантастический, но все было более-менее. Выпускается ли что-то по этому процессу сейчас - мне не известно. Как минимум, подозреваю, что есть существенные проблемы с изготовлением фотошаблонов.
В каком-то смысле это так, потому что степперы, в отличие от CAD не качаются из интернета и не размножаются так легко. Но работать без суппорта и на устаревших версиях - такое себе удовольствие :D
Эти утверждения обычно относятся все-таки не к температуре пучка, а к температуре кварк-глюонной плазмы, которая с почти любой практической точки зрения термодинамически равновесна.
В порядке бреда - возможно, в процессе синтеза PrPc он попадает в метастабильное состояние с очень большим временем жизни, потому что "печатается" рибосомой последовательно и выгодная конформация начала белка отличается от выгодной конформации ее же в полностью собранном белке?
Но я не настоящий сварщик, поэтому это всего лишь предположение :)
Единственный (известный мне) способ сообщить компилятору, что сущность объявлена в другом TU - это extern. Лайфтайм такого объекта будет начинаться со старта программы.
Пожалуй, если объявить все объекты такого типа (скажем, регистры устройства) как extern, а потом связать их линкером, то все будет корректно. Безусловно, это очень удобный метод. Особенно подходит для всяких динамических сущностей и перемещаемых (например, с помощью MMU) объектов :D
А здесь речь не о том, что происходит доступ к объекту, который с точки зрения компилятора не вызывает сайд-эффектов, а о том, что объекта никакого нет. Поэтому и доступа никакого быть не может.
Undefined behaviour с точки зрения компилятора целиком - это ситуация, когда нет никаких ограничений на действия генерируемого кода.
После того, как код сгенерирован, его поведение полностью определено, по крайней мере у всех известных мне процессоров общего назначения.
Стандарт не говорит о том, код с каким поведением должен быть сгенерирован при попытке сделать ваше *((*volatile int)0x3) = 1. Большинство современных компиляторов сгенерируют то, что вы ожидаете. От этого этот код не становится валидным и никаких гарантий, что так будет всегда нет.
О том и речь. Программа соответствует грамматике cpp, компилируется, даже код какой-то генерируется, но не является программой на cpp (содержит ub).
Видите ли в чем тут дело. C++ - это такой язык, на котором не все синтаксически корректные программы являются валидными. Это, в свою очередь означает, что программа может компилироваться, запускаться и делать что-то похожее на то, что ожидается, но при этом, фактически не быть программой на C++.
STM HAL именно такой. Это не C++ библиотека, а библиотека, написанная на конкретном диалекте, предоставляемом определенным диапазоном версий g++-arm. Работает? Ну да. Потому что обычно собирается в стерильной среде строго определенным компилятором.
Но крайне не завидую, если по какой то причине придется переползать на другой компилятор или будущий стандарт.
Ага, и потом обычное дело - получить набор забавных спецэффектов при попытке запустить код, откомпилированный с -O3 вместо -O0, на котором все вроде как работало :D
Лично мне никогда не приходилось писать freestanding код на C++ (а необходимость что-то скастить таким образом может возникнуть только во freestanding или драйвере, на мой взгляд), но, насколько я помню стандарт, reinterpret_cast is implementation defined, но не является ub при касте инта к указателю на какой-нибудь простой тип.
И вроде даже при касте к сложному объекту, если с точки зрения с++ abstract machine этот объект валиден (это, скорее всего, потребует правок в компиляторе, но стандарт это явно не запрещает).
Вроде как проблему с implementation defined и убеждением абстрактной машины должен решать std::start_lifetime_as, но тут я повторюсь, что я не специалист.
Даже в C можно наесться при написании большого freestanding проекта, на C++ это, наверное, совсем весело.
Нет, к атомарности это не имеет никакого отношения. Это работает только тогда, когда x+c вызывает какой-то сайд-эффект. Сложение интегральных типов никаких сайд-эффектов не порождает.
Данная программа не является программой на C++, так как содержит в себе undefined behavior.
Тут не надо ничего смотреть кроме стандарта. Для интегральных типов это одно и то же. Как при этом ведет себя какой-либо компилятор - дело десятое. Тем более, что современный clang, что gcc сгенерируют один и тот же код с любым бэкэндом даже с -O0
Во-первых, их так и так надо резать, и пластиковые чипы тоже не ножницами вырезаются. Во-вторых, резать можно плазмохимическим травлением, что на таких объемах будет дешево.
Если резать дисковой пилой, то надо считать экономику, но по ощущениям будет меньше $100 (порядка 5 часов работы пилы и существенно меньше одного диска стоимостью ~$30-40).
Направление, безусловно, интересное, но с экономическим обоснованием что-то не вяжется.
Во-первых, у этого FlexiCore крайне низкая плотность. Для сравнения 65nm CMOS обеспечивает плотность порядка 800 Квентилей/мм^2, то есть их ядро будет занимать площадь 0.0025 мм^2. Понятно, что в таком случае доминирующую площадь будут занимать контактные площадки.
Во-вторых, стоимость пустой 300 мм пластины меньше $100, а "испеченной" по 65нм - - около $1800-$2000. С учетом потерь на выход годных порядка 5% (это номинальная величина для столь взрослого техпроцесса для чипов такой малой площади), предположим, что $2000. Таким образом, стоимость пластины для такого процесса - это 5% общей стоимости.
Пусть конечное устройство имеет размер 0.5x0.5 мм, что вполне достаточно для того, чтобы иметь такое ядро и десяток контактных площадок. С учетом скрайб-линий, чипов с пластины получается примерно 200К. Таким образом, стоимость исходной пластины - 0.05 цента, стоимость процесса - 0.95 цента. То есть, как бы тоже более-менее попадает в границу 1 цента.
Насколько я понимаю, этот MPW запуск был сделан на GF по тому же техпроцессу, который должен был ставиться на этом оборудовании. По крайней мере, когда мне в нем предлагали поучаствовать, руководство фаба утверждало именно это.
Боюсь, что не разобрались-то именно вы и автор этого треда.
Вообще, просто какое-то вязкое ощущение ужаса возникает в сознании, когда понимаешь, что такой же уровень компетентности распространен не только среди людей, которые кричат в интернетах, что наконец-то открылись сказочные возможности импортозамещения и мы сейчас все рванем вперед, но и среди людей, непосредственно отвечающих за это самое импортозамещение.
Микроархитектуры firestorm и icestorm, используемые в M1 - это внутренняя разработка Apple, так что нет, код не покупной. Безусловно, это никак не отменяет того факта, что даже если процессорные ядра покупные (а вообще в современных soc процессорные ядра - далеко не доминирующие ip по стоимости), кристаллы все равно разработаны тем, кем они разработаны. Интеграция, верификация и физдизайн - это тоже не самый простой процесс.
Они запатентовали не вид услуги, если вы про RU 2021667729. Это вообще не патент, как у них на сайте написано, а свидетельство о регистрации ПО.