Giter VIP home page Giter VIP logo

dev86's Introduction

This is a development environment for ELKS-86 and standalone 8086 code.

All you need to do is 'make' from the top directory and the main parts
of the package will be made. These can be tested by using the 'ncc'
program from the newly created bin subdirectory. (ncc is a varient of
the bcc driver program that doesn't need to be installed to be used).

Use 'make install' to install them.

Some other bits can be built by 'make other' and installed with
'make install-other'.

Note the the make files for the libraries can only be run using
GNU-make but version 3.82 has a bug (No. 30612) that prevents this
working properly.

If you want it to install under /usr/local instead you can specify
the prefix on the first make ie: 'make PREFIX=/usr/local' this is
remembered until 'make.fil' is rebuilt. 

The manual pages in the man subdirectory are matched to these programs,
there are also some hints for using as86 well.  The tests and bootblocks
directories give some example code.

The bcc command defaults to using /usr/lib/bcc/include and /usr/lib/bcc
the libraries _and_ include files are copied to these locations by
install.  This can be changed by overriding 'PREFIX=/usr/...' or
'LIBDIR=/usr/...' on the initial make. Also available in the
same way are the BINDIR, INCLDIR, ASLDDIR, MANDIR and ELSESRC.
The 'ELKSSRC=/usr/src/elks' variable can be altered if you have ELKS on
path different from the default or ELKSSRC=/dev/null uses the supplied
ELKS headers. The ASLDDIR variable can be used to move as86 and ld86
into the LIBDIR with 'ASLDDIR=$(LIBDIR)'. The final '/include' is added
to the end of INCLDIR.

In the unlikely event you're makeing a non-cross development environment
you can, on the initial make, do "make PREFIX=/' to have the libraries
and include files in 'Native' locations.

Note: These prefix options only effect the 'bcc.c' driver program and
      the install scripts, all the others get their paths from bcc.c.
      The ELKSSRC location can, however, greatly effect how the ELKS
      libraries are built.

If you don't want to install in the locations specified above there
is also a DIST= argument to make install that is used to specify the
distribution root to install to.

The last option is not to install at all. All the executables in the
bin directory can be moved to whereever you wish except for bcc and ncc.
To use bcc at any other location you can create a symlink from your
new location to the 'ncc' executable and it will be able to find
the libraries in the build directory:

eg:
  cp ar86 elksemu objdump86 $HOME/bin/.
  cp as86 as86_encap ld86 $HOME/bin/.	# Optional.
  ln -s `pwd`/ncc $HOME/bin/bcc

All the versions of the library are built by make; 'normal', 'fast',
'MSDOS', 'standalone' and Linux-i386.

You use the other libraries like this:
   'FAST'    	$ bcc -Mf prog.c -o prog
   Caller saves $ bcc -Mc prog.c -o prog
   MSDOS	$ bcc -Md prog.c -o prog.com
   Standalone	$ bcc -Ms prog.c -o prog.sys
   Linux-i386	$ bcc -Ml prog.c -o prog

The 'Fast' and 'Caller saves' versions alter the function call assember 
in an effort to make it smaller and faster.

The 'MSDOS' version creates _small_ model (64k+64k) COM files. Because
of DOS limitations the filesize is limited to about 65000 bytes but
the BSS and Stack can be upto 64k on top of that.

The 'standalone' version creates executables like normal ELKS a.out
files but with no operating system calls, just BIOS ones. These 
files are suitable for running on a bare machine started by one of
the boot blocks in the bootblocks subdirectory. If you add a '-d'
option to the link stage the a.out header will be removed.

The Linux-i386 version generates static Linux OMAGIC a.out programs,
they need neither elksemu nor a.out shared libraries to run. Unfortunatly
these can no longer be converted to ELF executables as Linux will not
execute unpageable ELF executables. To allow conversion to ELF if you
pass the '-z' flag to 'bcc -Ml' the linker will now create QMAGIC a.out
executables, these are somewhat larger but can be converted with objcopy.

If you want to install everything in one go just login as root an do:
$ make install-all

The as86 and ld86 with this are _different_ from the minimum version
needed for the linux-i386 kernel and can replace them, versions before
0.12.0 will not work with this version of bcc.

I suggest you install the kernel patch or load the module to allow
transparent execution of elks executables.  If you're using a post
2.1.43 or 2.0.36 kernel the only module you need is the binfmt_misc
driver configured like this:

echo ':i86-elks:M::\x01\x03\x20\x00:\xff\xff\xff\x83:/usr/bin/elksemu:' \
     > /proc/sys/fs/binfmt_misc/register

The elksemu executable must be stored in /usr/bin/elksemu or the above
line adjusted.

Previous kernel versions need a special module or patch described in
elksemu/README (All the options need the elksemu executable installed
correctly)

Copyrights
----------
The `bcc', 'as' and `ld' parts of the distribution are now covered by
the GPL.  The `bccfp' library now in the libc/i386fp directory is under
the LGPL. (Primary copyright holder Bruce Evans)

The contents of the libc and libbsd subdirectories are under the LGPL
with a few noted exceptions.  The programs in 'tests', elksemu, copt
and the bootblocks directory are under the GPL.  Dis88 is freely
distributable if the source is distributed also.  Unproto is freely
distributable as long as Wietse Venema <[email protected]> and the
"Mathematics and Computing Science Dept.  Eindhoven University of
Technology.  The Netherlands." is given credit.

In libc the regular expression routine and the printf/scanf functions are
not under LGPL, the former is 'freely distributable' the latter is public
domain.

See the COPYING file in this directory for the GPL and the COPYING file
in the libc directory for the LGPL.

--
Rob.                           (Robert de Bath <[email protected]>)

dev86's People

Contributors

jbruchon avatar lkundrak avatar tkchia avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dev86's Issues

ELKS says "bye bye" to DEV86

Information to anyone who could wonder about the ELKS remaining stuff in DEV86.

ELKS project (see https://github.com/jbruchon/elks) was tightly coupled to DEV86 until last year. ELKS has now finished its transition to a full build chain based on GCC-IA16 (see https://github.com/tkchia/gcc-ia16) and is no more linked to DEV86.

There are still many components in DEV86 related to ELKS, but they don't need to be maintained anymore by the ELKS contributors. So please consider them as 'residual' (or 'historical') elements.

Linker alignment in 16bit mode

The symbols in .bss segment are ALWAYS 4 byte aligned. That is probably a mistake. Only 'LONG' should be aligned to 4 bytes (in 16 or 32 bit code that does not matter, by that way we will keep the memory layout independent from compiler options.)

tempoffset = symptr->value;
symptr->value = ld_roundup(comsz[seg = symptr->flags & SEGM_MASK],tempoffset,bin_off_t);
comsz[seg] = symptr->value+tempoffset;

The program

int i1=5;
long l=1;
long bss_l;
char c3='3';
int i2=0x7fff;
char c2='3';

int bss_i1;
char bss_c3;
int bss_i2;
char bss_c2;

int main()
{
}
ld86 -i -d -T 0x100 -D 0x0000 -H 0xf000 -M
produces the following linker output
test _i1 3 00000000 R
test _l 3 00000002 R
test _c3 3 00000006 R
test _i2 3 00000008 R
test _c2 3 0000000a R
test _bss_i1 3 0000000c R C
test _bss_i2 3 00000010 R C
test _bss_c2 3 00000014 R C
test _bss_c3 3 00000018 R C
test _bss_l 3 0000001c R C
test _main 0 00000100 R

Compilation on macOS mojave fails with error in "tok_io.c"

I am trying to compile dev86 for use on macOS. However, when following the README instructions, I get the following error:

/Library/Developer/CommandLineTools/usr/bin/make -C unproto CC='cc' CFLAGS=' -O2 -fno-strict-aliasing -no-cpp-precomp' LDFLAGS='' PREFIX=/usr LIBDIR='/usr/lib/bcc' BINDIR='/usr/bin' ANSI='' unproto
cc -O2 -fno-strict-aliasing -no-cpp-precomp -w      -DREOPEN -c tok_io.c -o tok_io.o
tok_io.c:231:6: error: non-void function 'do_control' should return a value
      [-Wreturn-type]
            return;
            ^
tok_io.c:262:6: error: non-void function 'do_control' should return a value
      [-Wreturn-type]
            return;
            ^
tok_io.c:267:6: error: non-void function 'do_control' should return a value
      [-Wreturn-type]
            return;
            ^
3 errors generated.
make[3]: *** [tok_io.o] Error 1
make[2]: *** [unproto] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2

I cannot find this file and correct the error myself nor does recompiling seem to fix the issue. What is happening?

system / exec / spawn functions for MS-DOS target?

Hi,

I couldn't find it in bcc's c library. So I assume I have to do it by myself.
How would I start with that? Using 0x4B function from int21?

Do you know, if there is any lib around that I can use for looking at with a working system-like function?

ar.c rename of temporary libary fails on some platforms

if the destination already exists, rename (tempname, archive) will fail, add unlink() first:

ar.c:
if (!appendflag)
{
unlink(archive);
if (rename (tempname, archive))
{
printf("rename failed %d %s\n",errno,strerror(errno));
pfatal_with_name (tempname);
}
}

Compilation warning

Building dev86-0.16.20 by gcc-4.8.2 I'v got this compilation warning:
dbprintf.c:110:13: warning: incompatible implicit declaration of built-in function ‘strlen’ [enabled by default]

__mkargv es register changed, program name missing in argv[0]

in __mkargv.o the es register is modified during the processing of the arguments and never restored. At the same time we can correct the missing program name the arg[0].

extern int __psp;
extern int __envseg;

void set_program_name(__argv)
char ** __argv;
{
unsigned char *ptr;
int src,len;

__set_es(__envseg);
src=0;
while(__peek_es(src++)!=0)
{
    while(__peek_es(src++)!=0);
}
src+=2; // step over 0x0001
len=0;
while (__peek_es(src+len++)!=0);
ptr=sbrk(len);
__argv[0]=ptr;
while(len--)
{
    *ptr++=__peek_es(src++);
}

}

__mkargv(__argc, __argv)
int __argc;
char ** __argv;
{
int length, i, argc=1, s=0;
unsigned char *ptr, *p;
int es=__get_es();

set_program_name(__argv);

__set_es(__psp); /* Pointer to the args */
....
__set_es(es);
}

Aseembly output truncates without error (commit cf72284)

Commit cf72284 causes assembler output to be truncated without an error in some cases. Testing against a previously working ELKS tree shows elkscmd/ktcp/vjhc.c fails when bcc calls as86 because the assembler output is truncated with no errors indicated; I produced a good vjhc.s of size 205992 and a bad vjhc.s with size 23192; the last line of the good file says ! 0 errors detected while the bad file simply stops in the middle of the code output.

Coding style

It seems to me that the project doesn't have a consistent coding style between modules or even inside the same file. I think that scares a bit new contributors that can't figure out how to handle code changes and editor setting. I suggest to choose a way to write code and apply it to the whole project.

If you give me enough indication on your preferred style I would like to work on make all code conforming to it maybe using some modern tool like clang-format. Then I think that adding or changing code will be easier for everybody.

[PATCH] Add stdint.h

I'm leaving this here because pull requests won't let me cherry-pick it at this point. Compiling some programs for ELKS doesn't work because bcc doesn't include the C99 stdint.h header. This patch provides one. While bcc is obviously not a C99-compliant compiler, this header is used by a lot of programs today (including ones I wrote) and there's no good reason I can think of not to have it.

--- snip ---

From fa9c32e5e87d55b57d915f5bcf7fb5524f6b65ab Mon Sep 17 00:00:00 2001
From: Jody Bruchon <[email protected]>
Date: Sun, 8 Mar 2015 13:49:13 -0400
Subject: [PATCH] Add stdint.h header to recognize some C99 types

Note that this header is not 100% compatible with Linux targets.
No one uses bcc to make Linux executables these days, and the
only incompatibility is that a macro that gets the maximum of
size_t will return a value that's too low.

Signed-off-by: Jody Bruchon <[email protected]>

---
 libc/include/stdint.h | 189 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 189 insertions(+)
 create mode 100644 libc/include/stdint.h

diff --git a/libc/include/stdint.h b/libc/include/stdint.h
new file mode 100644
index 0000000..039e287
--- /dev/null
+++ b/libc/include/stdint.h
@@ -0,0 +1,189 @@
+/* Copyright (C) 1997,1998,1999,2000,2001,2006 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <http://www.gnu.org/licenses/>.  */
+
+/* 2015-03-08: Modified for Dev86 by Jody Bruchon <[email protected]> */
+
+/*
+ *     ISO C99: 7.18 Integer types <stdint.h>
+ */
+
+#ifndef _STDINT_H
+#define _STDINT_H      1
+
+#include <features.h>
+
+/* Exact integral types.  */
+
+/* Signed.  */
+
+/* There is some amount of overlap with <sys/types.h> as known by inet code */
+#ifndef __int8_t_defined
+# define __int8_t_defined
+typedef signed char            int8_t;
+typedef int                    int16_t;
+typedef long int               int32_t;
+#endif
+
+/* Unsigned.  */
+typedef unsigned char          uint8_t;
+typedef unsigned int           uint16_t;
+#ifndef __uint32_t_defined
+typedef unsigned long          uint32_t;
+# define __uint32_t_defined
+#endif
+
+
+/* Small types.  */
+
+/* Signed.  */
+typedef signed char            int_least8_t;
+typedef int                    int_least16_t;
+typedef long                   int_least32_t;
+
+/* Unsigned.  */
+typedef unsigned char          uint_least8_t;
+typedef unsigned int           uint_least16_t;
+typedef unsigned long          uint_least32_t;
+
+/* Fast types.  */
+
+/* Signed.  */
+typedef signed char            int_fast8_t;
+typedef int                    int_fast16_t;
+typedef long                   int_fast32_t;
+
+/* Unsigned.  */
+typedef unsigned char          uint_fast8_t;
+typedef unsigned int           uint_fast16_t;
+typedef unsigned long          uint_fast32_t;
+
+
+/* Types for `void *' pointers.  */
+#ifndef __intptr_t_defined
+typedef int                    intptr_t;
+#define __intptr_t_defined
+#endif
+typedef unsigned int           uintptr_t;
+
+
+/* Largest integral types.  */
+typedef long int               intmax_t;
+typedef unsigned long int      uintmax_t;
+
+
+/* The ISO C99 standard specifies that in C++ implementations these
+   macros should only be defined if explicitly requested.  */
+#if !defined __cplusplus || defined __STDC_LIMIT_MACROS
+
+/* Limits of integral types.  */
+
+/* Minimum of signed integral types.  */
+# define INT8_MIN              (-128)
+# define INT16_MIN             (-32767-1)
+# define INT32_MIN             (-2147483647-1)
+/* Maximum of signed integral types.  */
+# define INT8_MAX              (127)
+# define INT16_MAX             (32767)
+# define INT32_MAX             (2147483647)
+
+/* Maximum of unsigned integral types.  */
+# define UINT8_MAX             (255)
+# define UINT16_MAX            (65535)
+# define UINT32_MAX            (4294967295U)
+
+/* Minimum of signed integral types having a minimum size.  */
+# define INT_LEAST8_MIN                (-128)
+# define INT_LEAST16_MIN       (-32767-1)
+# define INT_LEAST32_MIN       (-2147483647-1)
+/* Maximum of signed integral types having a minimum size.  */
+# define INT_LEAST8_MAX                (127)
+# define INT_LEAST16_MAX       (32767)
+# define INT_LEAST32_MAX       (2147483647)
+
+/* Maximum of unsigned integral types having a minimum size.  */
+# define UINT_LEAST8_MAX       (255)
+# define UINT_LEAST16_MAX      (65535)
+# define UINT_LEAST32_MAX      (4294967295U)
+
+/* Minimum of fast signed integral types having a minimum size.  */
+# define INT_FAST8_MIN         (-128)
+# define INT_FAST16_MIN                (-32767-1)
+# define INT_FAST32_MIN                (-2147483647-1)
+/* Maximum of fast signed integral types having a minimum size.  */
+# define INT_FAST8_MAX         (127)
+# define INT_FAST16_MAX                (32767)
+# define INT_FAST32_MAX                (2147483647)
+
+/* Maximum of fast unsigned integral types having a minimum size.  */
+# define UINT_FAST8_MAX                (255)
+# define UINT_FAST16_MAX       (65535U)
+# define UINT_FAST32_MAX       (4294967295U)
+
+/* Values to test for integral types holding `void *' pointer.  */
+# define INTPTR_MIN            (-32767-1)
+# define INTPTR_MAX            (32767)
+# define UINTPTR_MAX           (65535U)
+
+
+/* Minimum for largest signed integral type.  */
+# define INTMAX_MIN            (-2147483647-1)
+/* Maximum for largest signed integral type.  */
+# define INTMAX_MAX            (2147483647)
+
+/* Maximum for largest unsigned integral type.  */
+# define UINTMAX_MAX           (4294967295)
+
+/* Limits of other integer types.  */
+
+/* Limits of `ptrdiff_t' type.  */
+# define PTRDIFF_MIN           (-32767-1)
+# define PTRDIFF_MAX           (32767)
+
+/* Limits of `sig_atomic_t'.  */
+# define SIG_ATOMIC_MIN                (-32767-1)
+# define SIG_ATOMIC_MAX                (32767)
+
+/* Limit of `size_t' type.  */
+/* FIXME: Linux target has a 32-bit size_t but who really uses that target? */
+# define SIZE_MAX              (65535U)
+
+#endif /* C++ && limit macros */
+
+
+/* The ISO C99 standard specifies that in C++ implementations these
+   should only be defined if explicitly requested.  */
+#if !defined __cplusplus || defined __STDC_CONSTANT_MACROS
+
+/* Signed.  */
+# define INT8_C(c)     c
+# define INT16_C(c)    c
+# define INT32_C(c)    c
+# define INT64_C(c)    c ## LL
+
+/* Unsigned.  */
+# define UINT8_C(c)    c
+# define UINT16_C(c)   c
+# define UINT32_C(c)   c ## U
+# define UINT64_C(c)   c ## ULL
+
+/* Maximal type.  */
+# define INTMAX_C(c)   c ## LL
+# define UINTMAX_C(c)  c ## ULL
+
+#endif /* C++ && constant macros */
+
+#endif /* stdint.h */
--
2.2.1

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.