Koйто му се учи ще яде, който се дърпа ще го пенсионират. На кашоните!
ИИ отся им се подиграва, как гледат новите технологии като индианци! 10 пъти го цитирах, за Свира.
Смислено приложение на АИ-то?
0 1 2 3 4 ...9 10 11 12 13 ...21 22 23 24 25 26
Ти, учешият ИИ си в пенсия и си бил пенсиониран вече 20 пъти, два от който си взимал по 7 лева на ден помощи.
Такъв беше законът тогава, после земах къмто 1500 средно. Първите месеци са повече, после намаляват.
Не е бил такъв законът малоумник, нали ти казах че 2011та година бях на борсата 60% от 2000лв бяха 1200 лева на месец. Ти си взимал 150 защото си бил никому ненужна 35 годишна джунка на минимална заплата.
Ето ти линк към мнението ми от декември 2024
Бе такъв беше законът, ся коя година е било ще видя, ако седят логовете в банкирането, толкова назад. После земах колкото ти казах.
Нали ти дадох снимка вчера че 2011-та година МОД остава 2000 лв. Отделно аз съм бил на борсата 2011-та година и получавах 1200. Как за теб законът е един а за мен друг? Датата освен че я издаде с факти я и потвърди вчера. Ти си бил и винаги ще бъдеш нископлатен общ работник и докато не го осъзнаеш това, никога няма да изкарваш добри пари.
Може да е било още по-рано. Не ми се спори. Гледай си твойта борса, и твойте пари, не се кахъри за мойте, мангал!
Може, ама не е било. Извадено като доказателство от теми в отделен форум. Мерси, общак!
това би вдигнало времето за линкване в пъти, отделно ще изгенерира огромен несъбираем в микроконтролер бин. линкера затова иска входна точка, за да тръгне да линква от нея, самия той не знае хардуера отдолу как точно подава управлението на входната точка и не го интересува, това си го правиш ти като линкваш и разни векторни таблици. входната точка е само за да се стартира процеса на ликване, за нищо друго.
на ниво линкер това работи, може би компилатора ти ги реже не линкера, изобщо липсват в обектния файл. сложи им атрибут used и си готов, компилатора ще ги запази
С ник Рабин винаги давам умишлена грешка, да не прави fingerprint. И гледай си твойте подаяния, ти казах, в твойта паничка. Не ми бери кахъра на мене, то ако почна у всяко лайно по тротоара да се вглеждам, по сяка мастикя камък да хвърлям - няма да стигна закъдето съм тръгнал!
Чърчил.
Колкото и да те учудва линкера работи точно както ти казах на ниво обектен файл. Програмиста си решава как да раздели по обектни файлове. Като цяло няма проблем с големината на крайния файл. Пък като има анализираш и му търсиш решението.
Тц. Всичко си е във обектният файл. Просто няма никаква публична функция която да липсва някъде другаде за да се добави този файл в общия кюп. Затова и се налага да се маркира с whole archive по време на линкване. Добре, че cmake позволява сравнително интелигентно решение макар и грозно като писане. Used атрибута е за компилатора да не разчисти нещо по време на компилация. Няма отношение към линкера. То е и логично - за да знае линкера, че има нещо с атрибут used, обектният файл трябва вече да е включен в крайния резултат т.е. няма как заради used да вкараш нещо насила. Абе аз се оправих и всичко си работи. Просто не ми идва достатъчно елегантно решението за високите стандарти на които съм свикнал 
Да знам. Грешката е че си взимал 1500 помощи. Тук няма кой да излъжеш, всички виждаме какъв сварен картоф си
Като си превсключа банкирането щи ги снимам ве, гледай си твойта мизерия, ти казах. Само да не са ги изтрили, че беше отдавна.
Кви помощи вземам не е твоя работа!
е как нали самите функции които ти искаш да ползваш за обслужване на прекъсванията пасват на имената в таблицата и линкера ще открие тях, това е повод за включване. може би не ти разбирам целта на задачата.
Почти го хвана. Значи наистина публичното нещо е тази таблица. Само, че тя се събира от всички файлове по време на линкване и се вкарва в една голяма линкерска секция. Т.е. ако файла вече е в кюпа ще участва и в тази секция/таблица. Ако обаче не е и няма никакви други публични символи в него по които да бъде вкаран в кюпа то остава нелинкнат.
Евентуално проблема би се решил ако можеше да кажа на линкера - обиколи всички библиотеки и за всеки обектен файл тях провери ако има линкерска секция с дадено име и линкни тези обектни файлове. За съжаление линкера не работи така и трябва да го насилвам с whole archive.
Друго решение би било ако от cmake мога да кажа - искам те този .c/.o файл да бъде линкнат. А то сега първо влиза в .а библиотека и евентуално тази библиотека се ползва после по време на линкване.
Абе проблема е концептуален. Моята концепция не пасва с тази на линкера и затова нещата са грозни. А не искам пък да наблъскам сорса с ifdef-и защото тогава имам един файл който трябва да знае всички останали. Т.е. с тоя дизайн успях да избия цяло стадо зайци - като имаш някъде евънт още линк тайм си закачаш хендлърите и не се налага в сорса нито да ги регистрираш ръчно нито в евънта да пишеш на ръка кои са му хендлърите както много хора правят без да осъзнават, че така правят хоризонтална зависимост в сорса между файловете и в един момент всичко се усложнява. Втория момент е, че този механизъм работи като вънешен интерфейс или RPC т.е. така мога да извикам функция която да свърши нещо без да се интересувам в кой файл е имплементирана. Това позволява правенето на общи библиотеки където вкарваш някаква логика примерно за парсване на протокол а самата физическа комуникация става в клиента на тази библиотека но викането става в обратна посока - така не се налага да пускаш калбаци наляво надясно и кода се намаля.
Не очаквах да не знаеш как работи линкъра. Waldorf е прав. Обектният файл се състои от фрагмент от машинен код, таблица от символи с флагове и адреси и таблица на места в машинния код, които трябва да се ъпдейтнат адресите на символите. Флаговете на символите показват дали са дефинирани в обектния файл или са недефинирани. Линкера не знае краят на функциите, нито пък го интересува. Той НЕ МОЖЕ да реше парчета от машинния код, или го включва целия или не го включва. Линкера не знае и нищо за статичните функции.
Значи линкера парсва всички обектни файлове, включително и тези в библиотеките и събира всички символи на едно място. След това започва да resolve-ва кои символи са му необходими. Честно казано не знам дали ти или waldorf е прав за първоначалното състояние (т.е. дали всички споменати .о файлове се включват или се започва от стартиращия символ), но това не е много важно. След като знае кои символи му трябват, линкера взима фрагментите от машинен код и ги налепя заедно в code segment. Накрая използва таблицата на места в машинния код където символите се използват за да ъпдейтне адресите там с реалните адреси от code сегмента.
Линкерите, които могат да правят LTO могат да решават по време на свързването какво да махат от обектните файлове, ако решат могат да inline функции и т.н. Обикновено в тоя случай обектните файлове не съдържат машинен код, а са нещо като IR/BC representation-a на LLVM.
Линкера е длъжен да вкара всички explicit-но указани файлове от командния ред. Това си е по дизайн/спецификация.
А за LTS - тука нещата са малко по сложни. По точно е да се каже, че това всъщност е отложена компилация която се изпълнява по време на линкване когато вече е ясно какво ще влезе и какво не в крайния файл. Това позволява да се правят cross border оптимизации които компилатора иначе не може да направи защото е ограничен до един .c/.o файл. И чак накра имаме финално линкване. Абе вуду магия е.
Т.е. линкера и компилатора работят в тандем и трябва да могат да се разберат какво точно да правят. Не знам дали разните алтернативни линкерги като gold и т.н. поддържат LTO
добре де, но ти твърдиш че той точно това не прави - подаваш му обектен файл и той не търси в него. ще ме накараш да го пробвам
пробвах го, правя чист файл съсследното:
#include "apm32f051.h"
void USART1_IRQHandler(void){
u8 c=USART1->RXDATA;
USART1->TXDATA=c;
}
просто ехо от серийния, по прекъсване
нищо друго няма, линквам си това дето го човъркам към обектния и работи както се очаква - връща ехо от серийния
0 1 2 3 4 ...9 10 11 12 13 ...21 22 23 24 25 26