FP Detection [WAS]RE: Turbo C
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 - "So what are you gonna put on your resume...DUMB ASS?!?!" - Red Foreman of That '70s Show On Fri, 30 Jul 1999, Greg Haerr wrote: > 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 talking about OS support of math > : > coprocessors... > : > : On machines with coprocessors the the coprocessor state needs to be saved > : with the rest of the process context. Isn't being done now. Problem is it > : makes the context bigger and the swap longer. How long is an FSAVE on an > : 8087? > : > I see. Does anyone have any code for auto-detection of an 8087/8287/8387? > > Admittedly ELKS probably doesn't need FP, but my MicroWindows main demo > does have a 3d graphics demo that requires floating point, it'd still be nice to run >it ;-) > > gh >
RE: Turbo C
: 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
RE: Turbo C
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 talking about OS support of math : > coprocessors... : : On machines with coprocessors the the coprocessor state needs to be saved : with the rest of the process context. Isn't being done now. Problem is it : makes the context bigger and the swap longer. How long is an FSAVE on an : 8087? : I see. Does anyone have any code for auto-detection of an 8087/8287/8387? Admittedly ELKS probably doesn't need FP, but my MicroWindows main demo does have a 3d graphics demo that requires floating point, it'd still be nice to run it ;-) gh
Vacation
Hi all, I will be away on vacation for the next two weeks, so will not be doing any kernel related work in that time. My plan was to release the work I have done over the last few weeks this afternnon, but I have just broken the code, and can't fix it in time, so it is not worth releasing at the moment. Al
Re: Turbo C
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 > > coprocessors... > > On machines with coprocessors the the coprocessor state needs to be saved > with the rest of the process context. Isn't being done now. Problem is it > makes the context bigger and the swap longer. How long is an FSAVE on an > 8087? Can't we (you) mark in the process table if the process needs its F-registers saved? Jakob
Re: Apple ][ Unix Revisited
> Isn't xinu just a bunch of programs? Well, from what i recall, Xinu is another Unix-Like system, I think based on Minix. It stands for (X)inu (I)s (N)ot (U)nix. Ever actually used but, but there are versions for almost any platform you can think of.
Re: Turbo C
> 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 coprocessor state needs to be saved with the rest of the process context. Isn't being done now. Problem is it makes the context bigger and the swap longer. How long is an FSAVE on an 8087? Eric
RE: Apple ][ Unix Revisited
On Thu, 29 Jul 1999, Greg Haerr wrote: > : The Problem is that the Tarball has no filename information in it, so > : all the contents just spit put into one large file that I can't use. > : > Sounds like something a typical Apple ][ hacker would do... ;-) > > Tell me where it is, I'd like to see this. > > gh Isn't xinu just a bunch of programs? Jakob
Re: Apple ][ Unix Revisited
On Thu, 29 Jul 1999, legacy 'Xunker' wrote: > The Problem is that the Tarball has no filename information in it, so > all the contents just spit put into one large file that I can't use. The package you found must have been corrupted. I made a quick search on ftp-search and it found: ftp://ftp.apple.asimov.net/pub/apple_II/images/masters/apple2xinu.tar.gz That tarball has a readme, few gifs and three disk-images. According to readme, the images include sources and binaries for Xinu on Apple2. - Riba
