Re: Turbo C

1999-08-07 Thread Louis P. Santillan

The TP  TC files are at htt://community.borland.com/museum/

Louis

-
"So what are you gonna put on your resume... DUMB A** ?!?!"
  - Red Foreman of That '70s Show

On Thu, 5 Aug 1999, Luke (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 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 linker to produce ELKS executables.
  
 
 Where can I get it? I really would like Turbo C 1.0 for some old code I
 have.
 Luke(Boo) Farrar.
 
 
 



Re: Turbo C

1999-08-06 Thread Luke (boo) Farrar




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 mode compiler that can do the things we
 want, but it would need a back end linker to produce ELKS executables.
 

Where can I get it? I really would like Turbo C 1.0 for some old code I
have.
Luke(Boo) Farrar.




Re: Turbo C

1999-08-06 Thread Chad Page


I assume this is 'free beer' rather than 'free speech' but still,
way cool. :)

- Chad


On Thu, 5 Aug 1999, Luke (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 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 linker to produce ELKS executables.
  
 
 Where can I get it? I really would like Turbo C 1.0 for some old code I
 have.
 Luke(Boo) Farrar.
 
 
 



Re: Turbo C

1999-08-04 Thread Markus Leypold



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 it can
  be done with the 80x87:

* When You switch between processes, just 'lock' the 
  80x87, that an exception occurs, the next time, it
  is used.

* If an exception of this kind occurs, ask, wether the context
  in the 80x87 belongs to the task, which triggered the exception
  (the currently running task). If yes, just unlock it and resume.
  If no, the save the context. Load the float point context of the
  current task (if any) and resume.

  I'd like to call that 'lazy coprocessor context switch'. It amounts
  to not switching/saving/restoring the coprocessor context,
  if no or just one process uses the coprocessor, and else
  the context needs only switched, (n-1) times per scheduling
  , if n processes use the coprocessor. A lot of procs don't use it.


]

Regards -- Markus


-
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?
 
 Eric
 




RE: Turbo C

1999-07-30 Thread Greg Haerr


: 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



FP Detection [WAS]RE: Turbo C

1999-07-30 Thread Louis P. Santillan

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

1999-07-29 Thread David Murn

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 use it for compiling in the ELKS project.

You mean 'cross-compiling' (if it's not source).

Davey




RE: Turbo C

1999-07-29 Thread Greg Haerr

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 binaries?  If it's only binaries it's not much use to
: us.
: 
:  This means we can use it for compiling in the ELKS project.
: 
: You mean 'cross-compiling' (if it's not source).
:
No source code, binaries only for DOS.  We can't use it to compile ELKS
on Linux, but it's possible that it could be used on DOS.  Rob's dev86 would
be the first thing to get going...  He already has the devkit compiling using MSC 5.1.

Greg



RE: Turbo C

1999-07-29 Thread Greg Haerr

: 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 bcc primarily, unless you're talking about OS support of math
coprocessors...

Greg