Right BCC version to use ?

Right BCC version to use ?

[MFLD]

Hello all,

I wonder which BCC I should use to build ELKS and my tools.

I see in the main README that two versions are available:
1- https://github.com/lkundrak/dev86 (original)
2- https://github.com/jbruchon/dev86 (copy)

I currently use the version 1 that is provided in my Gentoo distribution.

Could you explain why you instruct to use the copy (version 2) in that 
README ?

Regards,

Marc-F. Lucca-Daniau

Re: Right BCC version to use ?

[Jody Bruchon]

I am adding things to my fork of bcc. lkundrak hasn't touched it since 2013 (which is not necessarily a bad thing). The only change I've made so far is writing a stdint.h header which allows use of the types specified in C99 such as int32_t and uint_fast8_t. The C99 types are needed to port some software to ELKS more easily. I intend to make modifications when needed for bug fixes and portability purposes.

ELKS is tightly tied to BCC for now, so some future development will probably require changes to it. A big difference between BCC and GCC is that BCC includes a C library and headers whereas GCC is only a compiler and requires a C library to be built separately. That means I can't fix issues with the C library without bringing the whole thing along.

Currently there is no need for my fork to build ELKS itself and I don't foresee that changing soon. If it does, I'll try to submit my patches upstream.

-Jody
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Right BCC version to use ?

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]

On 24/03/15 12:30, Jody Bruchon wrote:
[...]
> ELKS is tightly tied to BCC for now, so some future development will probably require changes to it. A big difference between BCC and GCC is that BCC includes a C library and headers whereas GCC is only a compiler and requires a C library to be built separately. That means I can't fix issues with the C library without bringing the whole thing along.

While I wouldn't suggest it for *new* development, because the compiler
technology is old and clunky and rather unmaintainable, but the ACK is
an ANSI C compiler suite which supports 8086 and comes with a full libc
--- this is what Minix used. It's even theoretically possible to run it
self-hosted on an ELKS-style machine, although it'd take work to recover
that ability these days. The 8086 coded generate isn't too bad. (Minix
was developed with it, after all.)

The downside is that it lives in its own little universe and doesn't
interoperate with anything; you have to use the ACK object file format
and the ACK linker etc. I believe it already supports Minix 16/16
segmented binaries.

The effort needed to persuade the ACK to produce ELKS executables is
probably quite small --- it already has partial support for ix86 and
m68k Linux; how different is the ELKS system call model? Making it build
the kernel is probably harder due to different dev86 and ACK linker magic.

This would only be worthwhile as a stopgap until 8086 gcc or pcc is
available, and it would need some careful evaluation of the code
quality, but it might be worth looking into.

The fairly elderly website is at: http://tack.sourceforge.net/

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Right BCC version to use ?

[MFLD]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

Hello,

I am afraid moving the current build chain to another compiler is too 
ambitious... and selecting another "exotic" compiler would not bring us 
back into the mainstream...

Back to the initial question, I finally moved to your bin86/dev86 fork 
by cloning your GIT repository. I added a .gitignore to have a more 
clear view on "git status" when doing some changes, please find it 
attached as a patch proposal (big things start with little steps).

Regards,

MFLD


Le 24/03/2015 22:50, David Given a écrit :
> On 24/03/15 12:30, Jody Bruchon wrote:
> [...]
>> ELKS is tightly tied to BCC for now, so some future development will probably require changes to it. A big difference between BCC and GCC is that BCC includes a C library and headers whereas GCC is only a compiler and requires a C library to be built separately. That means I can't fix issues with the C library without bringing the whole thing along.
> While I wouldn't suggest it for *new* development, because the compiler
> technology is old and clunky and rather unmaintainable, but the ACK is
> an ANSI C compiler suite which supports 8086 and comes with a full libc
> --- this is what Minix used. It's even theoretically possible to run it
> self-hosted on an ELKS-style machine, although it'd take work to recover
> that ability these days. The 8086 coded generate isn't too bad. (Minix
> was developed with it, after all.)
>
> The downside is that it lives in its own little universe and doesn't
> interoperate with anything; you have to use the ACK object file format
> and the ACK linker etc. I believe it already supports Minix 16/16
> segmented binaries.
>
> The effort needed to persuade the ACK to produce ELKS executables is
> probably quite small --- it already has partial support for ix86 and
> m68k Linux; how different is the ELKS system call model? Making it build
> the kernel is probably harder due to different dev86 and ACK linker magic.
>
> This would only be worthwhile as a stopgap until 8086 gcc or pcc is
> available, and it would need some careful evaluation of the code
> quality, but it might be worth looking into.
>
> The fairly elderly website is at: http://tack.sourceforge.net/
>


[-- Attachment #2: .gitignore --]
[-- Type: text/plain, Size: 750 bytes --]

# .gitignore for DEV86
# Ignore output files

# Object and archive files

*.o
*.a

# Output directories

bin/
lib/

# Output files

ifdefg
include
make.fil

ar/ar.h
ar/ar86
ar/rel_aout.h

as/as86
as/as86_encap
as/version.h

bcc/bcc
bcc/bcc-cc1
bcc/ncc
bcc/version.h

bootblocks/version.h

copt/copt

cpp/bcc-cpp

ld/ar.h
ld/ld86
ld/objdump86
ld/version.h

libc/.config.dir
libc/.config.lst
libc/error/error_list.h
libc/i386sys/syscall.c
libc/i386sys/syscall.mak
libc/include/arch
libc/include/linuxmt
libc/include/malloc.h
libc/include/regexp.h
libc/include/regmagic.h
libc/include/stdio.h
libc/include/string.h
libc/syscall/call_tab.v
libc/syscall/defn_tab.v
libc/syscall/syscall.c
libc/syscall/syscall.dat
libc/syscall/syscall.mak

unproto/unproto

Re: Right BCC version to use ?

[David Given]

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

On 27/03/15 19:03, MFLD wrote:
[...]
> I am afraid moving the current build chain to another compiler is too
> ambitious... and selecting another "exotic" compiler would not bring us
> back into the mainstream...

Yeah, I know, alas... I mentioned it because it's ANSI, it's small, and
it exists (which many people don't know).

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Right BCC version to use ?

[Jody Bruchon]

On 3/27/2015 2:03 PM, MFLD wrote:
> Back to the initial question, I finally moved to your bin86/dev86 fork
> by cloning your GIT repository. I added a .gitignore to have a more
> clear view on "git status" when doing some changes, please find it
> attached as a patch proposal (big things start with little steps).

I opted to build a .gitignore based on what Git said was untracked after 
a build; it covers all the files I could get the build process to output 
and you'll find it in my current Dev86 repo.

-Jody

Re: Right BCC version to use ?

[MFLD]

Thanks Jody for this quick patch!

Regards,

MFLD


Le 27/03/2015 23:12, Jody Bruchon a écrit :
> On 3/27/2015 2:03 PM, MFLD wrote:
>> Back to the initial question, I finally moved to your bin86/dev86 fork
>> by cloning your GIT repository. I added a .gitignore to have a more
>> clear view on "git status" when doing some changes, please find it
>> attached as a patch proposal (big things start with little steps).
>
> I opted to build a .gitignore based on what Git said was untracked 
> after a build; it covers all the files I could get the build process 
> to output and you'll find it in my current Dev86 repo.
>
> -Jody
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html