On Fri, 30 Jul 1999, Greg Haerr wrote:
> On Friday, July 30, 1999 10:31 AM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
>wrote:
> :
> I see. Does anyone have any code for auto-detection of an 8087/8287/8387?
Yes, You do :-)
Linux_8086/libc/misc/cputype.c
--
Rob.
(boo) Farrar wrote:
>
>
>
> On Thu, 29 Jul 1999, Perry Harrington wrote:
>
> > I brought up a thread a long time ago on this, Borland wasn't interested
> > then, but they just released Turbo C for free. This means we can use it
> > for compiling in the EL
this, Borland wasn't interested
> > then, but they just released Turbo C for free. This means we can use it
> > for compiling in the ELKS project.
> >
> > The idea would be to get a real mode compiler that can do the things we
> > want, but it would need a
On Thu, 29 Jul 1999, Perry Harrington wrote:
> I brought up a thread a long time ago on this, Borland wasn't interested
> then, but they just released Turbo C for free. This means we can use it
> for compiling in the ELKS project.
>
> The idea would be to get a real mo
Perhaps it is possible to run the Coprocessor in another Task and
trigger an exception exactly when the current task tries to use
the cp. This way You only would have to switch the cp context,
if more than one task actually uses the cp.
[
What I mean is s.th. like this (i'm not sure, wether
Group,
I was talking about Turbo C floating point context
switching, which is not very expensive from what I understand.
Dealing with a real mathco is another animal altogether.
scott
>>> Greg Haerr <[EMAIL PROTECTED]> 07/30/99 03:04pm >>>
On Friday, July 30, 1999 1
On Mon, 2 Aug 1999, Alex Holden wrote:
> On Fri, 30 Jul 1999, Greg Haerr wrote:
> > I see. Does anyone have any code for auto-detection of an
> > 8087/8287/8387?
> >From allegro/src/cpu.c:
I finally figured out where it's hiding in the NetBSD tree (the maths
coprocessor is an ISA device call
On Mon, 2 Aug 1999, Alex Holden wrote:
> On Fri, 30 Jul 1999, Greg Haerr wrote:
> > I see. Does anyone have any code for auto-detection of an
> > 8087/8287/8387?
> >From allegro/src/cpu.c:
Here's another one.
>From linux/arch/i386/kernel/head.S:
/*
* We depend on ET to be correct. This chec
On Fri, 30 Jul 1999, Greg Haerr wrote:
> I see. Does anyone have any code for auto-detection of an
> 8087/8287/8387?
>From allegro/src/cpu.c:
/* is_fpu:
* Returns TRUE is the CPU has floating point hardware.
*/
static int is_fpu()
{
int result;
asm (
" fninit ; "
"
I believe detection of math coprocessor is often done by either calling
INT 0x11 (result in AX) or reading the 16-bits at 0x40:0x10. Bit 1 being
the truth flag of the processor's presence. There are other ways of
finding out too.
Louis
-
: Can't we (you) mark in the process table if the process needs its F-registers saved?
:
On boot, determine if mathco present. If so, all process switches
save/restore the F regs.
gh
On Friday, July 30, 1999 10:31 AM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
wrote:
: > ELKS doesn't yet support floating point. The bcc compiler libraries have
: > support for 32 bit floating point though. All ELKS float support will have
: > to come from bcc primarily, unless you're talkin
On Fri, 30 Jul 1999, Eric J. Korpela wrote:
> > ELKS doesn't yet support floating point. The bcc compiler libraries have
> > support for 32 bit floating point though. All ELKS float support will have
> > to come from bcc primarily, unless you're talking about OS support of math
> > coproces
> ELKS doesn't yet support floating point. The bcc compiler libraries have
> support for 32 bit floating point though. All ELKS float support will have
> to come from bcc primarily, unless you're talking about OS support of math
> coprocessors...
On machines with coprocessors the the copr
: I don't think ELKS has floating point support yet, Alistair would be the best
: person to ask this question to, I think.
:
ELKS doesn't yet support floating point. The bcc compiler libraries have
support for 32 bit floating point though. All ELKS float support will have
to come from bc
>
> Perry,
>
> Cool! Thanks for the heads-up on that one. Excellent 16-bit compiler.
>
> I used Turbo C several years doing firmware development for an embedded
> 80c186 processor.
>
> We did not use DOS nor BIOS; we had the Paradigm "locate" program and
: The idea would be to get a real mode compiler that can do the things we
: want, but it would need a back end linker to produce ELKS executables.
:
Not if we added back MSDOS binary support in the kernel. This
would be fairly simple to add. We wouldn't have MSDOS emulation, just
the b
On Thursday, July 29, 1999 11:16 AM, David Murn [SMTP:[EMAIL PROTECTED]] wrote:
: On Thu, 29 Jul 1999, Perry Harrington wrote:
:
: > I brought up a thread a long time ago on this, Borland wasn't interested
: > then, but they just released Turbo C for free.
:
: Source, or just free bi
On Thu, 29 Jul 1999, Perry Harrington wrote:
> I brought up a thread a long time ago on this, Borland wasn't interested
> then, but they just released Turbo C for free.
Source, or just free binaries? If it's only binaries it's not much use to
us.
> This means we can
I brought up a thread a long time ago on this, Borland wasn't interested
then, but they just released Turbo C for free. This means we can use it
for compiling in the ELKS project.
The idea would be to get a real mode compiler that can do the things we
want, but it would need a back end l
20 matches
Mail list logo
