Re: Mbld: Open Questions.
[Thread Prev] | [Thread Next]
[Date Prev] | [Date Next]
- Subject: Re: Mbld: Open Questions.
- From: Ori Bernstein <ori@xxxxxxxxxxxxxx>
- Date: Fri, 26 Dec 2014 20:35:42 -0800
- To: Daniel Cegiełka <daniel.cegielka@xxxxxxxxx>
- Cc: myrddin-dev@xxxxxxxxxxxxxx
Ok, I think the solution I'm going to go with: Each platform will have a set of "platform tags". So, for example, Linux 3.12 on AMD64 with AVX might have the following platform tags: posixy, linux, amd64, avx, inotify, cgroups, ... OpenBSD may have: posixy, openbsd, amd64, kqueue, ... and so on. To select the file to compile, if any attribute is not in the target platform's platform attributes, it will be rejected immediately. Then, the number of platform attributes that are present in the file name are counted, and the one with the most matching attributes wins. If there are multiple files with equal numbers of attributes, this is an error. For example: encrypt.myr encrypt+sse.myr encrypt+sse-avx.myr encrypt+openbsd-avx.myr If we were compling on Linux with a recent CPU, we would first eliminate the file with the openbsd tag. Then, we would see that encrypt.myr has 0 matching tags, encrypt+sse.myr has 1 matching tag, and encrypt+sse-avx.myr has 2 matching tags. Therefore, we would select encrypt+sse-avx.myr However, if we added the following file to the list: encrypt+avx.myr we shoudl error out, as encrypt+sse.myr has 1 matching tag as well, and we don't know which to select. Even though in reality, AVX implies SSE. How does this sound? On Sun, 14 Dec 2014 12:58:07 +0100 Daniel Cegiełka <daniel.cegielka@xxxxxxxxx> wrote: > > At the moment, my makefiles have a rule that looks like: > > > > %.myr: %-$PLATFORM.myr > > cp $@-$PLATFORM.myr $@.myr > > > > Which allows you to have a platform specific myrddin file, and get > > the appropriate one selected. Right now, mbld does a relatively crude > > form of this, in that it will recognize .myr files with a +platform.myr, > > +platform-arch.myr, or +arch.myr suffix, and compile them. At the moment, > > it has no knowledge of specificity, though, so it will get confused if > > you have a foo.myr and a foo+linux.myr. Which one will get built is kind > > of up in the air at the moment. > > > > How do we want to handle this? Should myrbuild handle this, and know > > about platform filtering, or am I barking up the wrong tree? I've seen > > someone suggest making the Myrddin toolchain just expand environment > > vars in use files, so you would be able to do "use foo$sys.myr" to > > include the right file. I like the idea, but it has the disadvantage > > of not allowing fallbacks. > > There is another problem, which is not affected here. What with the > optimization of the specific cpu's instructions (SSE2, AVX, AVX2). > It's important for eg. crypto code (+arch-sse2.myr, +arch-avx.myr, > +arch-avx2.myr ??). -- Ori Bernstein <ori@xxxxxxxxxxxxxx>
Mbld: Open Questions. | Ori Bernstein <ori@xxxxxxxxxxxxxx> |
Re: Mbld: Open Questions. | Daniel Cegiełka <daniel.cegielka@xxxxxxxxx> |
- Prev by Date: Re: Mbld: Open Questions.
- Previous by thread: Re: Mbld: Open Questions.
- Next by thread: Re: Mbld: Open Questions.
- Index(es):