On Tue, 07 Feb 2012 16:38:33 -0500 Jody Bruchon <jody@xxxxxxxxxxxxxxx> wrote: > On 02/07/12 09:49, Harley Laue wrote: > > On 02/05/2012 11:14 PM, Jody wrote: > >> Hello everyone on the ELKS list; check this out: > >> > >> http://elks.git.sourceforge.net/git/gitweb.cgi?p=elks/elks;a=summary > >> > >> Took me a few hours to get right, but there it is, for better or > >> worse. You're welcome. ;-) Now I'm going to bed. > >> > >> Jody Bruchon > > Just a curious question, is there a reason you decided to have > > elks, elkscmd, and elksnet in the same repo instead of splitting > > them into their own git repos? > The simplest reason is that it was far easier to do it all in one > shot (IOW: I'm lazy); additional thoughts include: I can understand where you're coming from with that :) > * It's all one big project (i.e. ELKS the kernel is useless without > commands to run) I've personally never found that a very compelling argument. The same could be said about glibc, bash, etc to the Linux kernel. Having also studying the BSD source repos, I'm not terribly against it either to be honest. > * It seems that these components are tightly tied to each other > (really, what use is elkscmd without the ELKS kernel?) Well, I was just able to compile sash, bc, byacc, & file_utils and run them unaltered on an x86_64 Linux box. Granted some seem more tightly tied in (ash, elvis, and rc I also tried without any luck.) I guess my argument for this being split, if you want to call it an argument, is this is more like busybox (or the GNU tools) and the kernel is its own thing which may or may not use this as its interface. Basically the kernel should be able to run any program the user may want, not necessarily tied to elkscmd. > * elksnet is minuscule and shouldn't have its own repository; if > anything, I feel it should be merged into elkscmd. Agreed. Probably elksutils would be a candidate to merge in as well. > * I'm a minimalist and a pragmatist, and while the command sources > should be split from the kernel sources, I see no reason to dump them > into different repos; without an obvious and practical good reason to > add that extra complication, I won't. I did this back in 2009 with and it was only four commands to export each partial repo. (One for elks, elkscmd, elksnet, & elksutils.) *shrugs* > Of course, if I'm wrong in that choice, we should talk about why. > Honestly, at this stage, ELKS is in very real danger of dropping into > irrelevance and left to rot forever. I could care less if every > command had its own git repo, so long as people are working on the > project! I completely agree that I'd love to see people working on the project above all else. I just thought I'd bring this up at an early stage so if needed/wanted it could still be easily changed without much hassle to anyone who's still interested in the source. > Additionally, I'd like to assemble a list of open-source compilers > that can build for 8086 and either are targeted to other 16-bit CPUs > or can be relatively easily retargeted (I use that term loosely with > compilers. If anyone has suggestions for alternative compilers, > please email me with them, and I'll build a list and examine the > merits of each against the others. The only ones I know of are tcc > (by Fabrice Bellard), SDCC (targets Z80 but maybe we can retarget > it)...and the venerable Bruce's C Compiler (bcc) which we already > use. I dug up the original (non-Dev86) source for it and the 6809 > target parts are in that version, so maybe I can figure out how to > retarget it if I can dig up a 6809 emulator somewhere. SDCC may be an option, but it would need quite a bit of work to do the retarget. I've used this compiler for the Z80 and it works quite well and is the only one of the three mentioned that is still actively maintained/updated (and supports a few other 8 & 16 bit processors.) Another possibility might be to add 8086 support to LLVM. I doubt LLVM would be interested in having the support built in, but SDCC may actually accept patches to target 8086-80286 processors. Another possibility that looks to already support i86 is ACK (The Amsterdam Compiler Kit.) It looks to be pretty up-to-date and maintained as well. -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
