Writing OS in PASCAL.
fam. Svanfeldt.
Hi!
Is it posible to write OS in Borland Turbo Pascal 6.0 ?
And could I use RAWRITE to write it to a bootdisk?
*******************************************************
Mårten Svanfeldt
m_sva...@geocities.com
swanknit....@atvidaberg.mail.telia.com
******************************************************
Lithron
fam. Svanfeldt. wrote:
> =
> Hi!
> Is it posible to write OS in Borland Turbo Pascal 6.0 ?
> And could I use RAWRITE to write it to a bootdisk?
I'm not an expert on this, but I believe that even if it was possible,
it would be illegal by way of Borlands legal agreement with you.
Also, Assuming you know enough programming to make an OS in pascal,
why not just make one in ASM?
lith=BF
Danne F
On Mon, 19 May 1997, Lithron wrote:
> Date: Mon, 19 MAY 1997 15:09:32 -0400
> From: Lithron <lit...@bellsouth.net>
> Newgroups: comp.lang.pascal.borland, comp.lang.pascal.misc, comp.os.misc,
> swnet.sys.ibm.pc
> Subject: Re: Writing OS in PASCAL.
Hur skulle det kunna vara olagligt?
Later ganska underligt...
/Daniel
Dr E. Buxbaum
Lithron <lit...@bellsouth.net> wrote:
>fam. Svanfeldt. wrote:
>> =
>
>> Hi!
>> Is it posible to write OS in Borland Turbo Pascal 6.0 ?
>> And could I use RAWRITE to write it to a bootdisk?
>
>I'm not an expert on this, but I believe that even if it was possible,
>it would be illegal by way of Borlands legal agreement with you.
>
>Also, Assuming you know enough programming to make an OS in pascal,
>why not just make one in ASM?
Nobody would nowadays program a project of this size entirely in ASM. The
effort to maintain such a program (or group of programs) would be to
great. Such programs are written in high level languages, with some ASM
thrown in for direct hardware access or in performance critical routines.
TP from version 6 onward could do this easily because of the build in
assembler, BP could even generate 32 bit OSs. At least one command
interpreter, 4DOS, is in fact programmed mostly in TP (and boy would I
love to see their source!).
Most OS today are programmed in C, so if you want to look at examples,
you have to learn this language. Linux would be an obvious place to start
looking, as the complete source code is available.
As to the leagal side I can not see a problem. The only thing Borland
does not allow you to do are programs that are in direct competition to
their stuff (Pascal compilers for example). They don't do OSs, so there
is no competition.
Larry D. Barchett
"Dr E. Buxbaum" <EB...@le.ac.uk> (if that's who you really are) wrote:
>Nobody would nowadays program a project of this size entirely in ASM. The
>effort to maintain such a program (or group of programs) would be to
I guess somebody should have told Jochen Liedtke that before he wrote L4 ;-)
(although as a microkernel, it is technically not a complete operating system...)
ldb
--
---
Preserve wildlife.
Pickle a squirrel today.
---
/===================================================================\
|........Go!........ Larry D. Barchett |
|....NNN.....NNN.... Department of Computer Science and Engineering |
|.....N.N.....N .... University of Notre Dame |
|..DDDDDDNDDDDDDD... Notre Dame, IN 46556-5637 |
|...D.N...N...N..D.. |
|..DDDDDDDDNDDDDD... Internet: l...@cse.nd.edu |
|.....N.....N N..... |
|....NNN.....NNN.... Phone: 219-631-5772 |
|.......IRISH....... WWW: http://www.cse.nd.edu/~dcrlab/ldb |
\===================================================================/
Magnus Myhrberg
Lithron wrote:
>
> fam. Svanfeldt. wrote:
> >
> > Hi!
> > Is it posible to write OS in Borland Turbo Pascal 6.0 ?
> > And could I use RAWRITE to write it to a bootdisk?
>
> I'm not an expert on this, but I believe that even if it was possible,
> it would be illegal by way of Borlands legal agreement with you.
>
> Also, Assuming you know enough programming to make an OS in pascal,
> why not just make one in ASM?
>
Why should he use assembler? Nowdays we use highlevel languages like
C/C++ even when writing OS, so I can not se any problems here,
of couse he can use Pascal. But sometimes a assembler rutine can speed
up thing really much. But if you can live with that, go a head use
Pascal.
Magnus
------ ------
-- If [DELETE_THIS] is found in my mail adress, just do it! --
------ ------
smudge
fam. Svanfeldt. (swanknit....@atvidaberg.mail.telia.com) wrote:
: Hi!
: Is it posible to write OS in Borland Turbo Pascal 6.0 ?
: And could I use RAWRITE to write it to a bootdisk?
If the question is whether Pascal has enough capabilities to be used
as an OS language then the answer is yes. After all, the first version
of the Chorus microkernal was written in Pascal.
--smudge
jbgibson
Magnus Myhrberg wrote:
>
> Lithron wrote:
> >
> > fam. Svanfeldt. wrote:
> > >
> > > Hi!
> > > Is it posible to write OS in Borland Turbo Pascal 6.0 ?
> > > And could I use RAWRITE to write it to a bootdisk?
> >
> > it would be illegal by way of Borlands legal agreement with you.
> >
> > Also, Assuming you know enough programming to make an OS in pascal,
> > why not just make one in ASM?
> >
> > lith¿
>
> Why should he use assembler? Nowdays we use highlevel languages like
> C/C++ even when writing OS, so I can not se any problems here,
> of couse he can use Pascal. But sometimes a assembler rutine can speed
> up thing really much. But if you can live with that, go a head use
> Pascal.
>
> Magnus
>
> ------ ------
> -- If [DELETE_THIS] is found in my mail adress, just do it! --
> ------ ------
lines of code would this take?
David Firth
: > I'm not an expert on this, but I believe that even if it was possible,
: > it would be illegal by way of Borlands legal agreement with you.
Borland's No-Nonsense License doesn't say that you can't. In fact it says
that you may sell any app you create (in non-source form). While there
could be a technical argument that an OS is not an app, Borland's license
has always been pretty straight forward. If you write it, you may do
pretty much what you want with it w/o royalties.
: Why should he use assembler? Nowdays we use highlevel languages like
: C/C++ even when writing OS, so I can not se any problems here,
Although an OS would be tighest in asm, it would also be the least
portable and the hardest to debug. OS's are often written in an HLL
nowadays, and Modula-2 is a "child of Pascal" that was intended for system
work since it supports a type of multitasking called coprocessing. C was
the OS language for unix. HLL's are good for this kind of work (but not
every HLL -- you need some pretty low level hooks).
Assembler is best used by most people as a strategic tool for time
critical portions of code. Remember the 80-20 rule ...
--
------------------------------------------------------------------
David Firth N8PTK ! 52 45 41 4C 43 4F 4D 50 55 54 45
! 52 53 48 41 56 45 4F 4E 4C 59 38
djf...@freenet.columbus.oh.us ! 42 49 54 53 4D 45 43 38 32 30 31
Marc E. Fiuczynski
We've written on OS in Modula-3, which is a successor of Pascal.
Modula-3 supports threads, garbage collection, open arrays, and
just about whatever you need. A few things were implemented in
assembler (entry to trap handling, atomic enqueue/dequeue operations,
etc.).
I think that Pascal probably is a decent language to program an OS
in. However, I suggest that you look at Modula-3 instead. You can
get a very good free Modula-3 compiler from DEC SRC. Check it out:
http://www.research.digital.com:80/SRC/modula-3/html/
You can also get a commercial version of Modula-3 from Critical Mass.
http://www.cmass.com
try the evaluation copy of it. Both the DEC SRC and the Critical Mass
compilers work on Linux, hp/ux, windows NT 3.5.1, 4.0, and windows 95.
Many other platforms are supported, as well.
You can find out more about our operating system from
http://www.cs.washington.edu/research/projects/spin/www/index.html
Ciao,
Marc
Stephen Posey
On 20 May 1997 14:25:15 GMT, "Dr E. Buxbaum" <EB...@le.ac.uk> wrote:
[deletia]
>>Also, Assuming you know enough programming to make an OS in pascal,
>>why not just make one in ASM?
>
>Nobody would nowadays program a project of this size entirely in ASM. The
>effort to maintain such a program (or group of programs) would be to
>great. Such programs are written in high level languages, with some ASM
>thrown in for direct hardware access or in performance critical routines.
>TP from version 6 onward could do this easily because of the build in
>assembler, BP could even generate 32 bit OSs. At least one command
>interpreter, 4DOS, is in fact programmed mostly in TP (and boy would I
>love to see their source!).
I **LOVE** 4DOS and have used it for years (almost as long as I've had
a PC). Even so, I had no idea that it was written in TP, how did you
find that out? Do you know if InCommand (their Windows command line
processor) is written in TPW/BPW? How about 4OS2? I wonder if JP
Software would be willing to at least offer advice on large projects
or difficult system access issues, into which they MUST have a great
deal of insight.
[deletia mas]
Learn something new every day!
Regards,
Stephen Posey
slp...@concentric.net
Dr E. Buxbaum
slp...@concentric.net (Stephen Posey) wrote:
>I **LOVE** 4DOS and have used it for years (almost as long as I've had
>a PC). Even so, I had no idea that it was written in TP, how did you
>find that out?
It says so in the manual (acknowledgement section).
J.E.Shidel
jbgibson wrote:
>
> Magnus Myhrberg wrote:
> >
> > Lithron wrote:
> > >
> > > fam. Svanfeldt. wrote:
> > > >
> > > > Hi!
> > > > Is it posible to write OS in Borland Turbo Pascal 6.0 ?
> > > > And could I use RAWRITE to write it to a bootdisk?
> > >
> > > it would be illegal by way of Borlands legal agreement with you.
> > >
> > > why not just make one in ASM?
> > >
> >
> > Why should he use assembler? Nowdays we use highlevel languages like
> > C/C++ even when writing OS, so I can not se any problems here,
> > up thing really much. But if you can live with that, go a head use
> > Pascal.
I've done alot of programimg in TP 5.5 and 7.0, and if you know what
your doing it is as fast as C, and for simple programs creates smaller
executables. And, if you want really fast programs, you can use TP's
built in assembler. I wrote several a replacements for TPs CRT unit, the
most recent version supports all "know" video modes, and doesn't try to
default you into text mode, and runs anywhere from 1x to 16x the speed
of Borland's unit (I must admit it only averages about 4x it's speed).
So, speed is not a problem, but writing a boot sector can be difficult
using a compiler that only wants to create exe files, but you can get
around this with a little creativity.
And, another problem is since Borland dropped there dos compiler,
creating
32-bit apps that will take advantage of 386+ machines is out of the
question. Unless you want to use one of those other pascal compilers.
The short of it is that it is very possible to write an OS in pascal,
but you will be left with a very long, time consuming pain in the neck.
An you will need a lot of luck to make it 100% compatable with any other
OS's.
--
J.E.Shidel Jr.
E-Mail: mailto:jesh...@bellatlantic.net
Alex M. Kostyshin
22 May 1997 08:41:54 -0400 David Firth wrote:
>
<skipped>
> portable and the hardest to debug. OS's are often written in an HLL
> nowadays, and Modula-2 is a "child of Pascal" that was intended for system
> work since it supports a type of multitasking called coprocessing. C was
> the OS language for unix. HLL's are good for this kind of work (but not
> every HLL -- you need some pretty low level hooks).
>
> Assembler is best used by most people as a strategic tool for time
> critical portions of code. Remember the 80-20 rule ...
>
> --
> ------------------------------------------------------------------
> David Firth N8PTK ! 52 45 41 4C 43 4F 4D 50 55 54 45
> ! 52 53 48 41 56 45 4F 4E 4C 59 38
> djf...@freenet.columbus.oh.us ! 42 49 54 53 4D 45 43 38 32 30 31
--
//rgds, alex
U.S SURGEON GENERAL'S WARNING: MS-DOS is More Addictive Than Nicotine.
*===============================================*
| Alexey M. Kostyshin, |
| Ukrainian Lingvo-Information Fund NASU |
| Head of networking Departament |
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
| E-mail: al...@umif.freenet.kiev.ua |
| um...@olinet.isf.kiev.ua |
| Phone: 380-44-229-5156 (daytime) |
| 380-44-244-1802 (private) |
*===============================================*
Stephen Posey
Awwww, man! You mean I actually have to sit down and RTFM to find out
cool stuff like this? No, wait, that's what UseNet is for! ;-)
Stephen Posey
slp...@concentric.net
Kim Robert Blix
djf...@freenet.columbus.oh.us (David Firth) once said:
>Although an OS would be tighest in asm, it would also be the least
>portable and the hardest to debug.
Hardest to debug?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Kim Robert Blix ( kb...@sn.no & http://home.sn.no/~kblix )
"How do you shoot the devil in the back?"
"What if you miss?" -Verbal Kint
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Anthony Q. Bachler, BAS
Least portable? Lets see. I can get a PC with a pentium, a server with 2
pentiums, and an RS-6000 with 8 i960's (RISC pentiums I believe). Gee,
Wally, why does my code have to be portable again?
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer
meets the definition of a telephone fax machine. By Sec.227(b)(1)(C),
it is unlawful to send any unsolicited advertisement to such equipment.
By Sec.227(b)(3)(C), a violation of the aforementioned Section is
punishable by action to recover actual monetary loss, or $500,
whichever is greater, for each violation. All incoming unsolicited
commercial traffic will therefore be billed at a rate of $500 per msg
to compensate for loss of service.
Kim Robert Blix wrote in article <33853056...@news.sn.no>...
Anthony Q. Bachler, BAS
Just because Borland dropped their line of dos C compilers doesn't mean
"badda bing, badda bang, C for DOS is dead". It just means that Borland
won't be getting any more business from real programmers like me. Besides,
Turbo ASM supports 32-bit operations. That means that some skillful C/ASM
programmer will undoubtedly write a new compiler to replace the Borland TCC
that just converts C into ASM and compiles it with TASM. Programmers are
really starting to get fed up with having to buy "bigger, better, bulkier,
new, cutting edge, pricey, get yours today, for a limited time only, while
supplies last, not available in all areas, price does not include tax, void
where taxed or restricted, no warranty expressed or implied, use at your
own risk, do not taunt magic happy ball, use only under the close
supervision of an adult". programming tools that really only end up
forcing one to learn a whole new interface and don't make better code.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer
meets the definition of a telephone fax machine. By Sec.227(b)(1)(C),
it is unlawful to send any unsolicited advertisement to such equipment.
By Sec.227(b)(3)(C), a violation of the aforementioned Section is
punishable by action to recover actual monetary loss, or $500,
whichever is greater, for each violation. All incoming unsolicited
commercial traffic will therefore be billed at a rate of $500 per msg
to compensate for loss of service.
J.E.Shidel wrote in article <3384DC...@bellatlantic.net>...
Jeff Younker
"Anthony Q. Bachler, BAS" <cwhi...@sockets.net> writes:
> Least portable? Lets see. I can get a PC with a pentium, a server with 2
> pentiums, and an RS-6000 with 8 i960's (RISC pentiums I believe). Gee,
The i960 (the decendent of the i860) and the 80x86 family of processors
are completely unrelated products. The machine codes are about as
different as you can find.
Just to keep this topical, as I understand it the original Macintosh
operating system was written in pascal. Does anybody have any programmer's
docs to back this up?
- Jeff Younker - je...@mdli.com - These are my opinions, not MDL's -
Jude Giampaolo
In article <5m7gvk$c...@news.sockets.net>, "Anthony Q. Bachler, BAS"
<cwhi...@sockets.net> wrote:
> Least portable? Lets see. I can get a PC with a pentium, a server with 2
> pentiums, and an RS-6000 with 8 i960's (RISC pentiums I believe). Gee,
> Wally, why does my code have to be portable again?
The i960 has nothing to do with the Pentium besides the fact that they are
both made by Intel. RS-6000s don't have i960s in them anyway. The current
modes have PPC chips and the older ones were based on the Power chip set.
--
Jude Giampaolo -- Penn State University -- Electrical Engineering
jcg...@psu.edu - ju...@smellycat.com - http://prozac.cwru.edu/jude/
IBS and The Space Cowboy
Jeff Younker wrote:
>
> "Anthony Q. Bachler, BAS" <cwhi...@sockets.net> writes:
>
> > Least portable? Lets see. I can get a PC with a pentium, a server with 2
> > pentiums, and an RS-6000 with 8 i960's (RISC pentiums I believe). Gee,
>
> are completely unrelated products. The machine codes are about as
> different as you can find.
>
> Just to keep this topical, as I understand it the original Macintosh
> operating system was written in pascal. Does anybody have any programmer's
> docs to back this up?
>
> - Jeff Younker - je...@mdli.com - These are my opinions, not MDL's -
in Pascal
David Firth
: >Although an OS would be tighest in asm, it would also be the least
: >portable and the hardest to debug.
: Hardest to debug?
Sure. Instead of thousands or tens of thousands of lines of Pascal code, think
about debugging hundreds of thousands of lines of asm code <shudder>.
The Brutsche Family
system in pascal?
-Phil Brutsche
Dr E. Buxbaum
"Anthony Q. Bachler, BAS" <cwhi...@sockets.net> wrote:
>Just because Borland dropped their line of dos C compilers doesn't mean
>"badda bing, badda bang, C for DOS is dead". It just means that Borland
>won't be getting any more business from real programmers like me. Besides,
>Turbo ASM supports 32-bit operations. That means that some skillful C/ASM
>programmer will undoubtedly write a new compiler to replace the Borland TCC
>that just converts C into ASM and compiles it with TASM. Programmers are
>really starting to get fed up with having to buy "bigger, better, bulkier,
>new, cutting edge, pricey, get yours today, for a limited time only,
Then why not use the gnu C- (or Pascal- or Ada- or...) compiler? They are
available for DOS, support 32 bit programming and are actively maintained
by a group of dedicated programmers. And they are available free for the
asking...
Kim Robert Blix
djf...@freenet.columbus.oh.us (David Firth) once said:
>: >Although an OS would be tighest in asm, it would also be the least
>: >portable and the hardest to debug.
>
>: Hardest to debug?
>
>Sure. Instead of thousands or tens of thousands of lines of Pascal code, think
>about debugging hundreds of thousands of lines of asm code <shudder>.
And the glorious moments when your pascal code appears to be written correctly,
but actually mess with something it shouldnt have? :) Then you love asm.
NoWhereMan
"fam. Svanfeldt." <swanknit....@atvidaberg.mail.telia.com> wrote
on 19 May 97 17:30:31 GMT:
>Hi!
>Is it posible to write OS in Borland Turbo Pascal 6.0 ?
>And could I use RAWRITE to write it to a bootdisk?
>
I am holding a book "Operating Systems -- concept and design"
(2nd ed) by Milan Milenkovic, McGraw-Hill International Editions, 1992
ISBN 0-07-112711-9.
There is an implementation of a Kernel of a Mutlitasking
Operating System (KMOS) written in Turbo Pascal: you might want to
check it out.
Regards,
kung.
===
Max F Lang
Jeff Younker wrote:
>
>
> Just to keep this topical, as I understand it the original Macintosh
> operating system was written in pascal. Does anybody have any programmer's
> docs to back this up?
Most of the code found in "Inside Macintosh" is either Pascal or
Pascal-like pseudo code. I remember it made it fun, since I was trying
to program the Mac in C, and I knew (and still know) little Pascal.
--
/\/\ax |_ang, ...persuing cutting-edge research into the
budding Unix guru. burgeoning field of Linux-induced insomnia!
-x-x-x-Get Dick at <http://www.nightstand.com>!-x-x-x-
CyberF|re
IBS and The Space Cowboy wrote:
>
> Jeff Younker wrote:
> >
> > "Anthony Q. Bachler, BAS" <cwhi...@sockets.net> writes:
> >
> > > Least portable? Lets see. I can get a PC with a pentium, a server with 2
> > > pentiums, and an RS-6000 with 8 i960's (RISC pentiums I believe). Gee,
> >
> > The i960 (the decendent of the i860) and the 80x86 family of processors
> > are completely unrelated products. The machine codes are about as
> > different as you can find.
> >
> > operating system was written in pascal. Does anybody have any programmer's
> > docs to back this up?
> >
> I have read in a few places that the original MAC OS was indead created
> in Pascal
of the OS was stored on ROM therefor queit hard to program in pascal.
I maybe wrong, but I have worked with Apples for a number of years and
that was the impression I got.
Robert Reimiller
CyberF|re <cybe...@rocketmail.com> wrote:
>I have always belived that the origanl programing was done in asm, Most
>of the OS was stored on ROM therefor queit hard to program in pascal.
>
language for that matter)?
Robert Reimiller
Jeff Younker
CyberF|re <cybe...@rocketmail.com> writes:
...
> > I have read in a few places that the original MAC OS was indead created
> > in Pascal
> I have always belived that the origanl programing was done in asm, Most
> of the OS was stored on ROM therefor queit hard to program in pascal.
> that was the impression I got.
Having an OS in ROM wouldn't make it any more difficult to write in
Pascal (or any other high level language) than in assembly. The end
result in both cases is assembly. That's what compilers do, they turn
a high level language into assembly. After that it's just a matter of
buring the assembly into the ROMs.
That said, I believe you are mistaken about most of the Mac's OS being
in ROM. Macs have always required a boot disk of some kind, and I've
never seen a Mac OS upgrade come on pack of ROM chips. The upgrades
always come on a disk of some kind.
Perhaps you are thinking of an Apple ][ class of machine?
Rune Moberg
In article <5njpn4$c2s$1...@usenet87.supernews.com>,
nos...@quest-net.com (Robert Reimiller) wrote:
>CyberF|re <cybe...@rocketmail.com> wrote:
>>I have always belived that the origanl programing was done in asm, Most
>>of the OS was stored on ROM therefor queit hard to program in pascal.
>>
>language for that matter)?
IMHO it's probably compiler/linker-technology related, rather than
language related.
E.g. some startupcode (in the BIOS) might not be able to access memory
before some initiation has been performed. Thus your compiler must
not produce any code that uses stack or anything...
If you can use C, then you most certainly could use Pascal. (and the
result would be far more stable when doing it in Pascal, in addition
to the shorter compiletime)
--
=\
*=- R.Moberg, CD-Player Pro info @ http://home.sn.no/home/mobergru
=/ my own webserver @ http://pumba.qsd.no
Asbjørn
Robert Reimiller wrote:
>
> CyberF|re <cybe...@rocketmail.com> wrote:
> >I have always belived that the origanl programing was done in asm, Most
> >of the OS was stored on ROM therefor queit hard to program in pascal.
> >
> Why would ROM based code be hard to program in pascal (or any other
> language for that matter)?
The only thing I can think of is the space, but that shouldn't matter,
or?
--
- Asbjørn / Lord Crc
Dan Green
Jeff Younker wrote:
> Having an OS in ROM wouldn't make it any more difficult to write in
> Pascal (or any other high level language) than in assembly. The end
> result in both cases is assembly. That's what compilers do, they turn
> a high level language into assembly. After that it's just a matter of
> buring the assembly into the ROMs.
Well, actually the end result of a compilation + linking is machine code
and not assembly.
/Dan
Dan Green
Rune Moberg wrote:
> IMHO it's probably compiler/linker-technology related, rather than
> language related.
>
> E.g. some startupcode (in the BIOS) might not be able to access memory
> before some initiation has been performed. Thus your compiler must
> not produce any code that uses stack or anything...
>
> If you can use C, then you most certainly could use Pascal. (and the
> result would be far more stable when doing it in Pascal, in addition
> to the shorter compiletime)
Why would Pascal be more stable than C? And why is compile time
a factor to consider on this matter?
/Dan
Jeff Younker
Dan Green <era...@krug.gsm.ericsson.se> writes:
Well all be darned. I did write assembly instead of machine code in several
places. Thanks for pointing out my braino.
Klaus Hartnegg
: Why would Pascal be more stable than C?
Read the CERT announcements about recently found security problems.
Which C program does *not* have a buffer overflow problem somewhere?
I have the impression all setuid root programs for unix should be
rewritten from scratch.
: And why is compile time a factor to consider on this matter?
Because it affects development time and thus cost.
--
Klaus Hartnegg, Institut fuer Biophysik, Hansa-Strasse 9a, D-79104 Freiburg
hart...@uni-freiburg.de http://www.brain.uni-freiburg.de/~klaus/
Rune Moberg
In article <339FE9...@krug.gsm.ericsson.se>,
Dan Green <era...@krug.gsm.ericsson.se> wrote:
>Why would Pascal be more stable than C? And why is compile time
>a factor to consider on this matter?
Pascal is way easier to read than C, thus helping maintainability
and productivity.
Compile time directly influences productivity. The more time you spend
compiling, the less time you get working on your code. And with C, you
definatively need more time reading/writing code! (atleast if you
want to be sure that you don't make silly mistakes that a decent Pascal
compiler would catch for you)
Thus, a C coder's workday:
1. write some code
2. compile (and get some coffee while you're at it)
2b. check for any warnings/errors, go back to 1. repeat as necessary
3. test and see if it crashes (the compiler will miss a couple of
ambiguities)
4. debug time (it probably crashed)
5. try and remember what you were doign, back to 1.
6. you might actually get some more time at the end of the day
to write some _more_ code. Congratulation, atleast you have job
security! (no one will be able to take over your project)
A Pascal coder:
1. write some code
2. compile and immediately go back to your code and make corrections,
the compiler will catch 95% of all mistakes
3. either write some _more_ code or make a small test run (old habits
die hard)
4. repeat
5. actually leave work at your convenience (8 hour day). No job security
though, because someone else will actually be able to read your code
and replace you if something happend to you.
6. spend time on the newsgroups, laughing at people that are so
unfortunate that they have to work with C.
(same difference between Object Pascal and C++: Only multiply C++'s compile
time with 2-4 and divide readability with 2)
David Director
Rune Moberg wrote:
>
> In article <339FE9...@krug.gsm.ericsson.se>,
> Dan Green <era...@krug.gsm.ericsson.se> wrote:
> >Why would Pascal be more stable than C? And why is compile time
> >a factor to consider on this matter?
>
> Pascal is way easier to read than C, thus helping maintainability
> and productivity.
>
> Compile time directly influences productivity. The more time you spend
> compiling, the less time you get working on your code. And with C, you
> definatively need more time reading/writing code! (atleast if you
> want to be sure that you don't make silly mistakes that a decent Pascal
> compiler would catch for you)
>
> Thus, a C coder's workday:
>
> A Pascal coder:
> [snip]
>
You're entitled to your opinion, of course; this is a "religious"
matter. But to those of us who regularly work in C (I've done little
else for the past 15 years), it's eminently readable and no harder
to debug than any other language.
Furthermore, why would a C compiler necessarily be slower than a Pascal
one? Especially if the Pascal compiler is doing so much more checking,
as you imply. I have rarely encountered a C module which takes more
than 15 seconds to compile. If your C code takes a long time to
compile, maybe that's because you're not structuring your code
properly!
The fact is that for *most* tasks, any language that you're familiar
with, will do; you should generally code in whatever language you are
most fluent in. There are certain tasks for which one language or
another is better, because it provides paradigms which more closely
map to that particular task. In that case, use it.
In the meantime, you're welcome to keep your Pascal; I'll stick with C.
-- David
Asbjørn
I dunno about other compilers, but djgpp spends about 30 seconds to
compile
my "hello world" program. (Turbo) Pascal takes less than 2 seconds.
(Both with
smartdrv installed, "of coz")
Patrick D. Rockwell
I know that this is old news, but about a year ago, there was a thread
on comp.lang.pascal.borland and other newsgroups called "Write your own
operating system". In one of the posts, someone posed a reason why you
might actually want an operating system that uses protected memory as
Dos does, (for reasons OTHER than maintaining backwards compatiblility)
instead of just allowing the user to have FULL access to the memory as
do the 32bit operating system. Dos anyone remember anything like this?
As far as I know, the only reason that Dos has protected memory is so
that it can be used by the 8088 microprocessor. Are there any other
advantages that protected memory might confere? Thanks.
Josh Lothian
Asbjørn wrote:
> > Furthermore, why would a C compiler necessarily be slower than a
> Pascal
> > one? Especially if the Pascal compiler is doing so much more
> checking,
> > as you imply. I have rarely encountered a C module which takes more
>
> > than 15 seconds to compile. If your C code takes a long time to
> > compile, maybe that's because you're not structuring your code
> > properly!
>
> I dunno about other compilers, but djgpp spends about 30 seconds to
> compile
> my "hello world" program. (Turbo) Pascal takes less than 2 seconds.
> (Both with
> smartdrv installed, "of coz")
>
As I have read in many postings to comp.os.msdos.djgpp, the djgpp is
notriously slow when compared to other, commericial, products, such as
Borland C++. In other words, a freeware compiler cannot be compared
to a commercial compiler such as Turbo Pascal. But if you want to speed
up DJGPP, you should also try adding a around a 4 meg ramdrive. That
incresaes the speed another 50% over Smartdrive.
--
Josh Lothian
http://user.icx.net/~tlothian
remove the NOSPAM to reply to this message
Alan M. Evans
Patrick D. Rockwell wrote:
I assume here that when you say protected memory that you are referring
to protected mode memory addressing. If that is the case then I think
you are somewhat misinformed. DOS is real mode, not protected mode, and
protected mode wasn't used by the 8088 processor.
As far as I know, the chief advantage of protected mode is that it
protects different segments of memory from each other. In terms of error
trapping, it is not difficult to see why this would be valuable to an
operating system: a program that crashes in one segment will not bring
the entire system down with it.
AME
Klaus Hartnegg
David Director (ddir...@sungardams.com) wrote:
: Furthermore, why would a C compiler necessarily be slower than a Pascal
: one? Especially if the Pascal compiler is doing so much more checking,
: as you imply. I have rarely encountered a C module which takes more
: than 15 seconds to compile.
They do more checking and Borland Pascal is a lot faster than most C compilers.
I have hardly ever seen any Turbo Pascal program to take 10 seconds to compile
even when rebuilding all units. That's measured on a 486 and yes some of
my programs are very complex and compile several dozends big units.
As for readabilidy that's dependend of course on your level of expertise
and especially if you have written it. Try to understand a huge C
program written by someone else who had little expertise.
Unfortunately this is required quite often in real world.
Klaus
Rune Moberg
In article <33A1BA...@sungardams.com>,
David Director <ddir...@sungardams.com> wrote:
>You're entitled to your opinion, of course; this is a "religious"
>matter. But to those of us who regularly work in C (I've done little
>else for the past 15 years), it's eminently readable and no harder
>to debug than any other language.
I've been working with C at work for the past half year (in addition
to some previous experience of course). That's far from 15 years, but
I do recognise shit when it hits me in the face (or any other part
of my anatomy I suspect).
>Furthermore, why would a C compiler necessarily be slower than a Pascal
>one? Especially if the Pascal compiler is doing so much more checking,
A decent Pascal compiler does it stuff with only a single pass. It's unit
format lends itself to smart linking as well, reducing the size of the
executable (no more blind linking everything inside an .o/.obj file).
Pascal is a strongly typed language, which makes it easy for the
compiler to catch most of the common mistakes. In addition, it's a well-
defined language, so a simple typo will keep your program from being
compiled if you overlook an assignment ':=' instead of a comparison
operator '='...
Speaking of units... A Pascal compiler will usually use these... They
consist of an interface part (corresponding to a .h file) and an
implementation part (which would usually be a .o file in the C world).
I.e. everything is contained in one file and it makes it a hell of alot
easier to have e.g. global variables. The compiler (instead of the linker)
will check that the function declaration matches it's implementation.
The compiler can also concentrate on block of code and strip out those
parts of a unit that isn't currently being used (smart linking on the
function level).
In my overview (which you responded too), I was fairly inaccurate;
I forgot to mention that in addition to coding, compiling and debugging,
a C coder might end up spending even more time battling with header files,
makefiles and stuff like that. A decent Pascal compiler will help its
users to concentrate on the important stuff -- coding.
>as you imply. I have rarely encountered a C module which takes more
>than 15 seconds to compile. If your C code takes a long time to
>compile, maybe that's because you're not structuring your code
>properly!
Or maybe I use a tool that changes the base header files so that a
complete build is performed every time? I guess that's not the language's
fault (yes, it is: they should have implemented a decent unit format
instead of .h's!), but a complete build using a Pascal compiler from
Borland is (on the slowest) twice as fast as the fastest C compiler.
>The fact is that for *most* tasks, any language that you're familiar
>with, will do; you should generally code in whatever language you are
The fact is that with equal experience in Pascal and C, a programmer
is way more productive with Pascal.
>In the meantime, you're welcome to keep your Pascal; I'll stick with C.
Good, less competition for me.
Anthony Q. Bachler, BAS
I disagree. I find C much easier to read. I think that some C programmers
and some pascal programmers just write shitty to read code. Also, any
program which is optimized will be very hard to read since the code will be
assuming lots of stuff and following the programmers thought pattern.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
My favorite books:
Turbo C/C++ the complete reference 0-07-881776-5
Tricks of the game programming gurus 0-672-30507-0
The 8088 and 8086 microprocessors 0-13-248337-8
PC interrupts 0-201-57797-6
Programmers technical reference 1-56276-016-5
Life, the universe, and everything ISBN unknown
The Art of War
The Prince
The Phone Book
My little black book
Rune Moberg wrote in article ...
>In article <339FE9...@krug.gsm.ericsson.se>,
>Dan Green <era...@krug.gsm.ericsson.se> wrote:
>>Why would Pascal be more stable than C? And why is compile time
>>a factor to consider on this matter?
>
>Pascal is way easier to read than C, thus helping maintainability
>and productivity.
>
>Compile time directly influences productivity. The more time you spend
>compiling, the less time you get working on your code. And with C, you
>definatively need more time reading/writing code! (atleast if you
>want to be sure that you don't make silly mistakes that a decent Pascal
>compiler would catch for you)
>
>Thus, a C coder's workday:
Anthony Q. Bachler, BAS
Except you can specify assembly output on Turbo C.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
My favorite books:
Turbo C/C++ the complete reference 0-07-881776-5
Tricks of the game programming gurus 0-672-30507-0
The 8088 and 8086 microprocessors 0-13-248337-8
PC interrupts 0-201-57797-6
Programmers technical reference 1-56276-016-5
Life, the universe, and everything ISBN unknown
The Art of War
The Prince
The Phone Book
My little black book
Dan Green wrote in article <339FE8...@krug.gsm.ericsson.se>...
>Jeff Younker wrote:
>> Having an OS in ROM wouldn't make it any more difficult to write in
>> Pascal (or any other high level language) than in assembly. The end
>> result in both cases is assembly. That's what compilers do, they turn
>> a high level language into assembly. After that it's just a matter of
>> buring the assembly into the ROMs.
>
>Well, actually the end result of a compilation + linking is machine code
>and not assembly.
>
>/Dan
>
Anthony Q. Bachler, BAS
Protected memory? DOS has no protected memory. A program is free to write
over the OS at any time. Now maybe in Protected Mode that might cause a
protection fault, but the 8088/8086 never had protected mode.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
My favorite books:
Turbo C/C++ the complete reference 0-07-881776-5
Tricks of the game programming gurus 0-672-30507-0
The 8088 and 8086 microprocessors 0-13-248337-8
PC interrupts 0-201-57797-6
Programmers technical reference 1-56276-016-5
Life, the universe, and everything ISBN unknown
The Art of War
The Prince
The Phone Book
My little black book
Patrick D. Rockwell wrote in article <33A2F6...@thegrid.net>...
Rune Moberg
In article <5o0s44$8...@news.sockets.net>,
"Anthony Q. Bachler, BAS" <cwhi...@sockets.net> wrote:
>I disagree. I find C much easier to read. I think that some C programmers
>and some pascal programmers just write shitty to read code. Also, any
>program which is optimized will be very hard to read since the code will be
>assuming lots of stuff and following the programmers thought pattern.
Oh you big awesome hacker you!
Seriously, are you telling me that a language so prone to errors is
easier to read than a strongly typed language which is also the
component of one of the most productive development tools known
to man? (Delphi if you didn't know)
void myawesomefunction(int **something) //pointer to a pointer, how much more
//convenient than a simple 'var' arg.
{
int i, j = *something; // is i and j assigned to that thing, or just j?
if (i=j | j==i) //one or two |'s? Ah, the compiler will catch this.
j = 0;
}
no mistakes in the above code, right? Easy to read too.
Now try 500 lines of that. 1000. 5000...
Then again, perhaps it's only me. After all, I spent ten minutes
before I realised the difference between '!' (logical not) and '^'
(binary complement), only discovered it when I hit CPU view in the debugger.
In Pascal it was so difficult that I had to choose between 'not' (logical
not) and 'not' (uhm... one's complement).
I guess you're just a more accurate (and probably slower) keyboard typist
than I am.
James Olsen
In article <jVxnz0Jf...@oslonett.no>, mobe...@oslonett.no says...
>In article <5njpn4$c2s$1...@usenet87.supernews.com>,
>nos...@quest-net.com (Robert Reimiller) wrote:
>>CyberF|re <cybe...@rocketmail.com> wrote:
>>>I have always belived that the origanl programing was done in asm, Most
>>>of the OS was stored on ROM therefor queit hard to program in pascal
>>Why would ROM based code be hard to program in pascal (or any other
>>language for that matter)?
>E.g. some startupcode (in the BIOS) might not be able to access memory
>before some initiation has been performed. Thus your compiler must
>not produce any code that uses stack or anything...
I may be mistaken, but I don't think any of the OS resides in ROM. What
resides in the ROM is the "toolkit" for the GUI. Even so, many of these
ROM-based routines are now overwritten/patched with RAM versions with the
newer version of the OS.
If I remember correctly, nearly all of the code in the "Inside Macintosh"
volumes is Pascal, which would lead me to believe that most of the original
code itself was in Pascal.
On a side note, I have written a pseudo-operating system in object pascal.
It's small and the OOP make it a snap. It is not a true OS because a machine
doesn't run on it, but it allows reading and writing of foreign formatted
diskettes in a PC machine using low-level BIOS calls. It features most DOS
commands like delete, copy, move, rename, etc.
Anyhow, take care.
--James Olsen
ja...@dpc.net
http://www.dpc.net/~james
webm...@soundcentral.com
http://www.soundcentral.com
Dan Green
Klaus Hartnegg wrote:
>
> : Why would Pascal be more stable than C?
>
Where can I do that?
> Which C program does *not* have a buffer overflow problem somewhere?
> I have the impression all setuid root programs for unix should be
> rewritten from scratch.
C and Pascal are related languages that are very similar. Both are
structured languages with similar syntax and operations. And I can not
see any reason why the language itself would result in a more instable
machine code than Pascal. Perhaps I am missing something?
> : And why is compile time a factor to consider on this matter?
>
> Because it affects development time and thus cost.
Compared to the amount of time spent during system design and coding,
the compilation times are more or less insignificant. Especially
considering the small size of most boot programs.
/Dan
Markus E. Leypold
On Sat, 14 Jun 1997, Asbj=F8rn wrote:
>=20
> I dunno about other compilers, but djgpp spends about 30 seconds to
> compile
> my "hello world" program. (Turbo) Pascal takes less than 2 seconds.
> (Both with
> smartdrv installed, "of coz")
>=20
> --=20
> - Asbj=F8rn / Lord Crc
>=20
In my humble opinion (and not wanting to start another war here), the
above mentioned compile time differences are correct as far as DJGPP
and TURBO PASCAL are concerned but has nothing to do with the=20
difference between C and PASCAL whatsowever. The DJGPP said something
about it, I can't remember too much of it, but it was something to the
effect, that because of loading the compiler ant initializing etc, it
takes a comparably short time to compile a long file. Also I think
DGJPP is a portabloe compiler and as thus not as efficient as a native
compiler as TURBO PASCAL (again this has nothing to do with the C -=20
PASCAL - controversy).=20
To sum up:=20
T : Compile Time
K,M : Constants characteristic for the Compiler
N : Number of lines of source code
T =3D K + M*N
with different K and M for TURBO PASCAL (TP) and DJGPP (DJ).
K(TP) is much smaller than K(DJ) whereas M(DJ) might only be slightly
larger than M(TP) (or even not that).=20
The example above, due to N being small, reflects only on the=20
ratio of the K's: K(DJ)/K(TP)=3D15.
=20
Best regards & much fun further on - Markus
Dan Green
Asbjørn wrote:
> I dunno about other compilers, but djgpp spends about 30 seconds to
> compile
> my "hello world" program. (Turbo) Pascal takes less than 2 seconds.
> (Both with
> smartdrv installed, "of coz")
I do not think that it is relevant to compare compile times based on
a simple module such as "hello world".
/Dan
Dan Green
> >Why would Pascal be more stable than C? And why is compile time
> >a factor to consider on this matter?
>
> and productivity.
I disagree. I have no problems what so ever to read well structured
C source code.
> Compile time directly influences productivity. The more time you spend
> compiling, the less time you get working on your code. And with C, you
> definatively need more time reading/writing code! (atleast if you
> want to be sure that you don't make silly mistakes that a decent Pascal
> compiler would catch for you)
That is very ignorant of you. I can promise you that I write/read C
source
as fast as you read/write Pascal dito. It is just a matter of
experience.
And as I said before, the time you spend compiling is insignificant in
relation to the real designwork.
> A Pascal coder:
> 1. write some code
> 2. compile and immediately go back to your code and make corrections,
> the compiler will catch 95% of all mistakes
> 3. either write some _more_ code or make a small test run (old habits
> die hard)
> 4. repeat
> 5. actually leave work at your convenience (8 hour day). No job security
> though, because someone else will actually be able to read your code
> and replace you if something happend to you.
> 6. spend time on the newsgroups, laughing at people that are so
> unfortunate that they have to work with C.
A real software designer:
1. Investigates the requirements
2. Divides the functionality into well defined modules
3. Writes a technical solution
4. Draws a flowchart
5. Implements the code
6. Compiles the code
6.1 Corrects minor mistakes
6.2 Recompiles the code
7. Tests the code
8. Releases the code to a happy user
/Dan
Dan Green
Rune Moberg wrote:
> void myawesomefunction(int **something) //pointer to a pointer, how much more
> //convenient than a simple 'var' arg.
> {
> int i, j = *something; // is i and j assigned to that thing, or just j?
>
> if (i=j | j==i) //one or two |'s? Ah, the compiler will catch this.
> j = 0;
> }
>
> no mistakes in the above code, right? Easy to read too.
> Now try 500 lines of that. 1000. 5000...
Well, you cheated since you wrote the above in C++ ;) But why do you
have to take the worst example? It is possible to write very ugly code
in pascal aswell.
/Dan
Kim Robert Blix
"Anthony Q. Bachler, BAS" <cwhi...@sockets.net> wrote:
>I disagree. I find C much easier to read. I think that some C programmers
>and some pascal programmers just write shitty to read code. Also, any
>program which is optimized will be very hard to read since the code will be
>assuming lots of stuff and following the programmers thought pattern.
if (x=14) ++y;
Its not easy to see the error in this line if its in the middle of a 600 lines
program. It will compile, but not like you expect. Not the mother of all
examples but hey!
--
Kim Robert Blix ( kb...@sn.no & http://home.sn.no/~kblix )
"How do you shoot the devil in the back?"
"What if you miss?" -Verbal Kint
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Asbjørn
Well 200-500 lines compiles in about 10 sec, so...
But this is rather a question about languages. The way c is buildt up,
makes it a bit "harder" to compile, and djgpp is 32bit pmode, and so
on...
Asbjørn
Alan M. Evans wrote:
>
> Patrick D. Rockwell wrote:
>
> > I know that this is old news, but about a year ago, there was a thread
> > on comp.lang.pascal.borland and other newsgroups called "Write your
> > own operating system". In one of the posts, someone posed a reason why
> > you might actually want an operating system that uses protected memory
> > as Dos does, (for reasons OTHER than maintaining backwards
> > compatiblility) instead of just allowing the user to have FULL access
> > to the memory as do the 32bit operating system. Dos anyone remember
> > anything like this?
> >
> > As far as I know, the only reason that Dos has protected memory is so
> > that it can be used by the 8088 microprocessor. Are there any other
> > advantages that protected memory might confere? Thanks.
>
> to protected mode memory addressing. If that is the case then I think
> you are somewhat misinformed. DOS is real mode, not protected mode, and
> protected mode wasn't used by the 8088 processor.
pmode came with the 286, and dos is pure rmode, but the user prog can
enter
pmode.
> As far as I know, the chief advantage of protected mode is that it
> protects different segments of memory from each other. In terms of error
> trapping, it is not difficult to see why this would be valuable to an
> operating system: a program that crashes in one segment will not bring
> the entire system down with it.
But if you see how it's implemented, it often does :)
Asbjørn
Asbjørn wrote:
>
> Alan M. Evans wrote:
> > As far as I know, the chief advantage of protected mode is that it
> > protects different segments of memory from each other. In terms of error
> > trapping, it is not difficult to see why this would be valuable to an
> > operating system: a program that crashes in one segment will not bring
> > the entire system down with it.
>
> But if you see how it's implemented, it often does :)
Hmm.. What i meant was: They way it's implemented it "often" does
(windows, do
i need to say more?)
Asbjørn
Dan Green wrote:
>
> Rune Moberg wrote:
> >
> > In article <339FE9...@krug.gsm.ericsson.se>,
> > Dan Green <era...@krug.gsm.ericsson.se> wrote:
> > >Why would Pascal be more stable than C? And why is compile time
> > >a factor to consider on this matter?
> >
> > Pascal is way easier to read than C, thus helping maintainability
> > and productivity.
>
> I disagree. I have no problems what so ever to read well structured
> C source code.
Well, that might be because you know c. I found it very hard to remeber
all those | and % and ^. What's so wrong with or, mod and xor? And
pointers?
Well, I haven't got them working either. And the way you can just start
using
a variable anywhere in the code, it's a real pain in the ass, if you ask
me...
> > Compile time directly influences productivity. The more time you spend
> > compiling, the less time you get working on your code. And with C, you
> > definatively need more time reading/writing code! (atleast if you
> > want to be sure that you don't make silly mistakes that a decent Pascal
> > compiler would catch for you)
>
> That is very ignorant of you. I can promise you that I write/read C source
> as fast as you read/write Pascal dito. It is just a matter of
> experience.
Which you gain much quicker using pascal, than c, i'm sure of...
> And as I said before, the time you spend compiling is insignificant in
> relation to the real designwork.
Is it? Ok, let's say you're working on a rather large project. Let's say
u
use watcom, not djgpp, and borland sucks, right? :) Now, make a little,
but
vital change, so that you need to rebuild the program. Those things
happen.
15minutes later, you're ready to see if the change was good. If you'd
used
pascal, you could have changed/copiled/tried like three times by now.
> > A Pascal coder:
> > 1. write some code
> > 2. compile and immediately go back to your code and make corrections,
> > the compiler will catch 95% of all mistakes
> > 3. either write some _more_ code or make a small test run (old habits
> > die hard)
> > 4. repeat
> > 5. actually leave work at your convenience (8 hour day). No job security
> > though, because someone else will actually be able to read your code
> > and replace you if something happend to you.
> > 6. spend time on the newsgroups, laughing at people that are so
> > unfortunate that they have to work with C.
>
> A real software designer:
>
> 1. Investigates the requirements
> 2. Divides the functionality into well defined modules
> 3. Writes a technical solution
> 4. Draws a flowchart
> 5. Implements the code
> 6. Compiles the code
> 6.1 Corrects minor mistakes
> 6.2 Recompiles the code
> 7. Tests the code
> 8. Releases the code to a happy user
Wow, just two compiles, and ready to sell? Well, that doesnt' sound like
any "real" programmer i've ever seen (or heard about). You think they
compiled
Quake only two times?
jnz
Rune Moberg (mobe...@oslonett.no) wrote:
:
: Pascal is way easier to read than C, thus helping maintainability
: and productivity.
Agreed here.
: Compile time directly influences productivity.
I have to disagree here. Regardless of the compiler used,
the time spent waiting for the compiler to finish is usually
insignificant compared to the time spent coding/debugging/etc.
Psychologically, the inpact is perceived as significant, but
if you actually go ahead and measure the actual time spent, it's
very small compared to other activities.
: The more time you spend
: compiling, the less time you get working on your code. And with C, you
: definatively need more time reading/writing code! (atleast if you
: want to be sure that you don't make silly mistakes that a decent Pascal
: compiler would catch for you)
:
: Thus, a C coder's workday:
: 1. write some code
: 2. compile (and get some coffee while you're at it)
: 2b. check for any warnings/errors, go back to 1. repeat as necessary
: 3. test and see if it crashes (the compiler will miss a couple of
: ambiguities)
: 4. debug time (it probably crashed)
: 5. try and remember what you were doign, back to 1.
: 6. you might actually get some more time at the end of the day
: to write some _more_ code. Congratulation, atleast you have job
: security! (no one will be able to take over your project)
:
: A Pascal coder:
: 1. write some code
: 2. compile and immediately go back to your code and make corrections,
: the compiler will catch 95% of all mistakes
: 3. either write some _more_ code or make a small test run (old habits
: die hard)
: 4. repeat
: 5. actually leave work at your convenience (8 hour day). No job security
: though, because someone else will actually be able to read your code
: and replace you if something happend to you.
: 6. spend time on the newsgroups, laughing at people that are so
: unfortunate that they have to work with C.
There's a big difference between compilers and compilers. I have
starrted out coding something under HP-UX using the native C
compiler. While some of the error messages I got was really
meaningless and they showed up far from the real error, the
compiler did generate some very useful warning messages about
unused or once used variables, conversion problems etc.
---
Reply-To: and From: fields have been altered to avoid spam.
Daniel Eriksson
Asbjørn wrote:
> Well, that might be because you know c.
---[snip]---
> And pointers? Well, I haven't got them working either.
If you don't know C you are in no position to speak of it's
alleged disadvantages.
> And the way you can just start using a variable anywhere in the
> code, it's a real pain in the ass, if you ask me...
That's C++, not C. And please note that it's POSSIBLE, not
MANDATORY!
Many people that complains about C/C++ do so by pointing out that
you CAN do this and that. They all seem to think it's mandatory
to use every strange notation and that the entries to the
obfuscated C contest is representative of the real world use
of the language.
> Is it? Ok, let's say you're working on a rather large project.
> Let's say u use watcom, not djgpp, and borland sucks, right? :)
> Now, make a little, but vital change, so that you need to rebuild
> the program. Those things happen. 15minutes later, you're ready to
> see if the change was good. If you'd used pascal, you could have
> changed/copiled/tried like three times by now.
Believe it or not, but trial'n'error is not the way if you want
to be a productive/effective programmer. Bad engineering practice
can to some degree be replaced by it, but at the end of the day
you'll get more work done if you know what you are doing instead
of guessing.
--
Daniel Eriksson, Software Engineer, Ericsson Radio Systems AB
Vinson ABS
Robert Reimiller <nos...@quest-net.com> wrote in article
<resurrect.5njpn4$c2s$1...@usenet87.supernews.com>...
> CyberF|re <cybe...@rocketmail.com> wrote:
> >I have always belived that the origanl programing was done in asm, Most
> >of the OS was stored on ROM therefor queit hard to program in pascal.
> >
> Why would ROM based code be hard to program in pascal (or any other
> language for that matter)?
Obviously BIOS/ROM codes are compact and ASM-oriented. Yes, you can write a
simple ROM code using Pascal but not our beloved IBM PC BIOS code. BIOS
code have a few absolute address that must remain at specific address. Your
ROM 8x8 character set is at FFFF:FA6Eh. If it is not there, you might not
see the words on QUAKE and some games. Some VGA ROM family has ID strings
on specific addresses to identify themselves and SVGA(not VESA) routines
needs them. I believe these are documented in the IBM BIOS
manual/reference, otherwise people don't even know of its existence.
High-level languages cannot reserve memory at specific addresses. Assembler
can do that because it is designed to do so. C/C++ is more on OS codes and
Pascal is more on general-purpose codes. OS can be written in C or Pascal.
It is the language extension that matters -- C/Pascal are worthless with
ASM extensions.
Have you ever heard of 4DOS? It is written in Pascal and ASM. I consider it
to be the finest command interpreter of all. NDOS is
cloned from 4DOS by Symantec.
There is a saying, "Killing a chicken with the butcher's cleaver". In this
case, it means to do something with wrong tools.
From Vinson ABS.
Dan Green
Asbjørn wrote:
>
> Dan Green wrote:
> > I disagree. I have no problems what so ever to read well structured
> > C source code.
>
Well, yes. And I think that most programmers who are using C/C++ knows
C/C++, don't you?
> I found it very hard to remeber
> all those | and % and ^. What's so wrong with or, mod and xor? And
> pointers?
I guess there is nothing wrong with it but | is shorter than OR ;)
> Well, I haven't got them working either.
Work harder...
> And the way you can just start using a variable anywhere in the code,
> it's a real pain in the ass, if you ask me...
I guess you are talking about the declaration of a variable anywhere in
the code a'la C++? Well, I do not see any problems with having the
option
of doing that. If it is good coding practice is a completely different
question though.
> > That is very ignorant of you. I can promise you that I write/read C source
> > as fast as you read/write Pascal dito. It is just a matter of
> > experience.
>
> Which you gain much quicker using pascal, than c, i'm sure of...
We could argue about that for ages I'm sure...
> > And as I said before, the time you spend compiling is insignificant in
> > relation to the real designwork.
>
> Is it? Ok, let's say you're working on a rather large project. Let's say
> u
> use watcom, not djgpp, and borland sucks, right? :) Now, make a little,
> but
> vital change, so that you need to rebuild the program. Those things
> happen.
> 15minutes later, you're ready to see if the change was good. If you'd
> used
> pascal, you could have changed/copiled/tried like three times by now.
But you do not work like that if you are involved in a large project.
The
above is true when you are writing shareware at home, drinking coke and
with a dirty GIF in the background. See below how real programmers do it
;)
> > A real software designer:
> >
> > 1. Investigates the requirements
> > 2. Divides the functionality into well defined modules
> > 3. Writes a technical solution
> > 4. Draws a flowchart
> > 5. Implements the code
> > 6. Compiles the code
> > 6.1 Corrects minor mistakes
> > 6.2 Recompiles the code
> > 7. Tests the code
> > 8. Releases the code to a happy user
>
> Wow, just two compiles, and ready to sell? Well, that doesnt' sound like
> any "real" programmer i've ever seen (or heard about). You think they
> compiled
> Quake only two times?
No, but I got bored ;) But seriously. In a large project coding and
compiling is a very small part. The optimal project only needs to
be compiled once. That is what every software company is aiming for.
Unfortunately this is not possible, but if you put a lot of effort
into solving the problems in the early system design you will get
it back later.
The typical project looks something like this:
55% Prestudy, system/function design
10% Coding, compiling
35% Test
/Dan
Dr E. Buxbaum
"Vinson ABS" <illu...@singnet.com.sg> wrote:
>
>High-level languages cannot reserve memory at specific addresses. Assembler
>can do that because it is designed to do so. C/C++ is more on OS codes and
>Pascal is more on general-purpose codes. OS can be written in C or Pascal.
>It is the language extension that matters -- C/Pascal are worthless with
>ASM extensions.
At least in TP you have had the option of using specified addresses at
least since version 2 (I never used version 1) with the Mem[] and MemW[]
arrays. It also has the Port[] array for access to hardware. And the handling
of Asm instructions in TP version 6 and later can hardly be improved upon.
Devlin
Dan Green wrote:
>
> The typical project looks something like this:
>
> 55% Prestudy, system/function design
> 10% Coding, compiling
> 35% Test
>
> /Dan
I find that my projects look something like this:
20% system/function design
20% coding, compiling
60% testing, debugging
:-)
--
God's final message to His creation: "We apologize for the
inconvenience"
URL: http://www.geocities.com/SiliconValley/Lakes/7568/index.html
My real e-mail address is locu...@geocities.com, but the spambots
don't
know that (yet)...
Devlin Wright. NOTICE: I will be OFF-LINE for 3 months from June 20th!!!
Dan Green
Vinson ABS wrote:
> Obviously BIOS/ROM codes are compact and ASM-oriented. Yes, you can write a
> simple ROM code using Pascal but not our beloved IBM PC BIOS code.
No, you can write very advanced ROM code (what is that anyway) using
both C
and Pascal. The memory type is not relevant.
> High-level languages cannot reserve memory at specific addresses. Assembler
> can do that because it is designed to do so.
How is that? I have yet to see an assembler instruction for allocating
memory, for any processor. And the reason for it is that memory
management
is usually part of the OS, not the processor instruction set.
> C/C++ is more on OS codes and
> Pascal is more on general-purpose codes.
And why is that?
> OS can be written in C or Pascal.
> It is the language extension that matters -- C/Pascal are worthless with
> ASM extensions.
Do you mean _without_ ASM? Well, I agree that assembler is sometimes
preferable,
but worthless without it? I don't think so...
/Dan
Olice Certain
Dan Green wrote:
(snip)
A lot of these.
> ;)
(Snip)
>
> > > A real software designer:
> > >
> > > 1. Investigates the requirements
> > > 2. Divides the functionality into well defined modules
> > > 3. Writes a technical solution
> > > 4. Draws a flowchart
> > > 5. Implements the code
> > > 6. Compiles the code
> > > 6.1 Corrects minor mistakes
> > > 6.2 Recompiles the code
> > > 7. Tests the code
> > > 8. Releases the code to a happy user
> >
> > Wow, just two compiles, and ready to sell? Well, that doesnt' sound like
> > any "real" programmer i've ever seen (or heard about). You think they
> > compiled
> > Quake only two times?
>
> No, but I got bored ;) But seriously. In a large project coding and
> compiling is a very small part. The optimal project only needs to
> be compiled once. That is what every software company is aiming for.
> Unfortunately this is not possible, but if you put a lot of effort
> into solving the problems in the early system design you will get
> it back later.
>
>
> 55% Prestudy, system/function design
> 10% Coding, compiling
> 35% Test
>
> /Dan
Well Dan, I don't know where you work as a "real software
designer", but I've spent over 8 years writing software for
other people. Typical of many programmers, I've changed
jobs frequently during my career.
I've written commercial software, systems level software
and corporate "in house" software. I've worked in groups
of programmers and as the only programmer. Along with my
main work, I've done a lot of after hours/weekend consulting
work.
I've found that, while many companies give a lot of lip
service to "Prestudy, system/function design", most will
short circuit the process in their rush to complete the
project and the typical project winds up looking more like
this:
15% Prestudy, system/function design
75% Coding, compiling
10% Testing
I wouldn't care to count the times I've had to recompile code
in a week much less during the entire development cycle. In
every project I've worked on the code is compiled and recompiled
*many* times. ;)
--
ocer...@webwide.net
--------------------------------------------------------------------
Please use this address when replying. The address in the header
has anti-spam verbage added. Hated to do it -but- I'm tired of all
the unsolicited spam finding it's way to my mail box.
--------------------------------------------------------------------
Asbjørn
Dan Green wrote:
>
> Asbjørn wrote:
> >
> > Dan Green wrote:
> > > I disagree. I have no problems what so ever to read well structured
> > > C source code.
> >
> > Well, that might be because you know c.
>
> Well, yes. And I think that most programmers who are using C/C++ knows
> C/C++, don't you?
I sure hopes so, but looking at all the m$ crap, i'm not that sure :)
> > I found it very hard to remeber
> > all those | and % and ^. What's so wrong with or, mod and xor? And
> > pointers?
>
> I guess there is nothing wrong with it but | is shorter than OR ;)
I find it very hard to read, but i guess it's just a matter of training.
> > Well, I haven't got them working either.
>
> Work harder...
Dloaded djgpp two days ago... Still have some trouble with them pointers
:)
> > And the way you can just start using a variable anywhere in the code,
> > it's a real pain in the ass, if you ask me...
>
> I guess you are talking about the declaration of a variable anywhere in
> the code a'la C++? Well, I do not see any problems with having the
> option
> of doing that. If it is good coding practice is a completely different
> question though.
Well, i find it very annoying, and what's the point?
> > > That is very ignorant of you. I can promise you that I write/read C source
> > > as fast as you read/write Pascal dito. It is just a matter of
> > > experience.
> >
> > Which you gain much quicker using pascal, than c, i'm sure of...
>
> We could argue about that for ages I'm sure...
:)
> > > And as I said before, the time you spend compiling is insignificant in
> > > relation to the real designwork.
> >
> > Is it? Ok, let's say you're working on a rather large project. Let's say
> > u
> > use watcom, not djgpp, and borland sucks, right? :) Now, make a little,
> > but
> > vital change, so that you need to rebuild the program. Those things
> > happen.
> > 15minutes later, you're ready to see if the change was good. If you'd
> > used
> > pascal, you could have changed/copiled/tried like three times by now.
>
> But you do not work like that if you are involved in a large project.
> The
> above is true when you are writing shareware at home, drinking coke and
> with a dirty GIF in the background. See below how real programmers do it
> ;)
Hehe, real programmers, as in m$ programmers? :)
> > > A real software designer:
> > >
> > > 1. Investigates the requirements
> > > 2. Divides the functionality into well defined modules
> > > 3. Writes a technical solution
> > > 4. Draws a flowchart
> > > 5. Implements the code
> > > 6. Compiles the code
> > > 6.1 Corrects minor mistakes
> > > 6.2 Recompiles the code
> > > 7. Tests the code
> > > 8. Releases the code to a happy user
> >
> > Wow, just two compiles, and ready to sell? Well, that doesnt' sound like
> > any "real" programmer i've ever seen (or heard about). You think they
> > compiled
> > Quake only two times?
>
> No, but I got bored ;) But seriously. In a large project coding and
> compiling is a very small part. The optimal project only needs to
> be compiled once. That is what every software company is aiming for.
> Unfortunately this is not possible, but if you put a lot of effort
> into solving the problems in the early system design you will get
> it back later.
M$ does it.... One compile, ready to give away...
> The typical project looks something like this:
>
> 55% Prestudy, system/function design
> 10% Coding, compiling
> 35% Test
You're missing a part, the part where you evaluate the program, see if
it's
"good", and perhaps make adjustments...
Dr John Stockton
In article <01bc7a49$6985a9e0$LocalHost@default> of Tue, 17 Jun 1997
05:10:10 in comp.lang.pascal.borland, Vinson ABS
<illu...@singnet.com.sg> wrote:
>
>Obviously BIOS/ROM codes are compact and ASM-oriented. Yes, you can write a
>code have a few absolute address that must remain at specific address. Your
>ROM 8x8 character set is at FFFF:FA6Eh. If it is not there, you might not
>see the words on QUAKE and some games.
It is not there ! actually a mere typo; it is at $F000:$FA6E
>
>High-level languages cannot reserve memory at specific addresses.
Consider the following program, tested in TP7.01 in a WfWg3.11 DOS box :
program Z ; uses Crt ;
type T1 = array [0..7] of byte ;
var A : array [#0..#127] of T1 absolute $F000:$FA6E ;
B : T1 ;
C, D, E : byte ; F : char ;
const X : array [boolean] of char = ' *' ;
BEGIN ;
repeat Write('Character (<End> to stop)? ') ; F := ReadKey ;
if F=#0 then begin F := ReadKey ; HALT end ;
B := A[F] ; Writeln ;
for C := 0 to 7 do begin D := B[C] ; Write(D:5, '':2) ;
for E := 0 to 7 do
begin Write(X[D>127]) ; D := (D and $7F) shl 1 end ;
Writeln end ;
until false ;
END.
It certainly seems to read the ROM character set ...
Your Message-ID: <01bc7a49$6985a9e0$LocalHost@default>
is broken.
From Son-of-RFC1036 :
5.3. Message-ID
The Message-ID header contains the article's message ID, a
unique identifier distinguishing the article from every
other article:
Message-ID-content = message-id
message-id = "<" local-part "@" domain ">"
...
The domain in the message ID SHOULD be the full Internet
domain name of the posting agent's host.
--
John Stockton, Surrey, UK. j...@merlyn.demon.co.uk Turnpike v1.12 MIME.
Web URL: http://www.merlyn.demon.co.uk/ -- includes FAQqish topics and links.
Correct 4-line sig separator is as above, a line comprising "-- " (SoRFC1036)
Before a reply, quote with ">" / "> ", known to good news readers (SoRFC1036)
James H. Haynes
A side note to all this is that the Burroughs machines starting with the
B5500 in early 1960s had the OS written in a dialect of Algol. It's
called ESPOL. B5500 ESPOL allowed inline assembler code, but it was
very sparingly used in the OS. I don't remember if B6500 and later ESPOL
allow assembler code - there is no assembler as such. The language does
have hooks that allow you go get to reserved memory locations and specify
the layout of machine words that contain fields of bits.
visa_harvey_abstr...@rincewind.craybbs.co.uk
Hello AsbjOrn!
Saturday June 14 1997 05:56, AsbjOrn wrote to All:
>> You're entitled to your opinion, of course; this is a "religious"
>> matter. But to those of us who regularly work in C (I've done
>> little else for the past 15 years), it's eminently readable and no
>> harder to debug than any other language. Furthermore, why would a C
>> compiler necessarily be slower than a Pascal one? Especially if the
>> Pascal compiler is doing so much more checking, as you imply. I
>> have rarely encountered a C module which takes more than 15 seconds
>> to compile. If your C code takes a long time to compile, maybe
>> that's because you're not structuring your code properly!
A> I dunno about other compilers, but djgpp spends about 30 seconds to
A> compile
A> my "hello world" program. (Turbo) Pascal takes less than 2 seconds.
A> (Both with
A> smartdrv installed, "of coz")
A big reason that pascal is faster ( usually ) to complie is that most pascal
compilers are Single pass instead of multiple pass like most C compilers, due
to the stricter syntax of pascal over C, thus the sam thing done in pascal will
probably compile faster than an equivalent C version, I wont say anything about
code efficiency as this is intirely ( ? ) dependant on the compiler, and I do
not have much knowledge on the subject anyway...
Visa
--
Rune Moberg
In article <5o5okb$6...@falcon.le.ac.uk>,
"Dr E. Buxbaum" <EB...@le.ac.uk> wrote:
>"Vinson ABS" <illu...@singnet.com.sg> wrote:
>>High-level languages cannot reserve memory at specific addresses. Assembler
>>Pascal is more on general-purpose codes. OS can be written in C or Pascal.
>>It is the language extension that matters -- C/Pascal are worthless with
>>ASM extensions.
>
>least since version 2 (I never used version 1) with the Mem[] and MemW[]
>arrays. It also has the Port[] array for access to hardware. And the handling
>of Asm instructions in TP version 6 and later can hardly be improved upon.
I think what Vinson was getting at was that you can't easily tell the
linker to put certain "variables" (constants actually) at a certain
position. This has nothing to do with the language chosen (of which
Assmbly sortof qualifies), but rather a more compiler/linker specific
topic.
In Borland Pascal you can use the "Absolute" keyword to position a
variable on a specific memory address. Thus you can map an array on
top of the display memory (text mode anyway) and directly modify
it without resorting to using Mem[]. I'm not sure if you can map
a constant the same way, but that was basically what (IMO) he was
talking about.
(A colleague of mine is actually doing just this; making startup
code for such a BIOS. I wish I knew more about the tools involved,
but I can confirm that it's all Assembly... No stack, no memory
access, etc...)
Rune Moberg
In article <01bc7a49$6985a9e0$LocalHost@default>,
"Vinson ABS" <illu...@singnet.com.sg> wrote:
>Have you ever heard of 4DOS? It is written in Pascal and ASM. I consider it
>to be the finest command interpreter of all. NDOS is
>cloned from 4DOS by Symantec.
4DOS is great, but I thought it was done in C? There was a NT (and OS/2)
version out long before I had even heard of any plans for a NT Pascal
compiler. The first commercial Pascal compiler for NT AFAIK was Delphi 2.0.
Dunno about GNU Pascal though... (I don't even know when GNU Pascal was
contracepted)
BTW: Talk about coincidence. I was just checking out jpsoft's site
this afternoon where I discovered a beta version of the next 4NT version...
Their site is at www.jpsoft.com for those who don't know.
Dan Green
Olice Certain wrote:
> I've found that, while many companies give a lot of lip
> service to "Prestudy, system/function design", most will
> short circuit the process in their rush to complete the
> project and the typical project winds up looking more like
> this:
>
> 15% Prestudy, system/function design
> 75% Coding, compiling
> 10% Testing
>
> I wouldn't care to count the times I've had to recompile code
> in a week much less during the entire development cycle. In
> every project I've worked on the code is compiled and recompiled
> *many* times. ;)
That is because your projects are compelled as stated above. Large
projects cannot be run like that, and they are not, generally.
/Dan
Dan Green
Asbjørn wrote:
>
> Dan Green wrote:
> > Well, yes. And I think that most programmers who are using C/C++ knows
> > C/C++, don't you?
>
> I sure hopes so, but looking at all the m$ crap, i'm not that sure :)
Hehe ;)
> > I guess there is nothing wrong with it but | is shorter than OR ;)
>
> I find it very hard to read, but i guess it's just a matter of training.
Exactly, experience. And I think that a prerequisite when you work on
project
with other programmers, is that everybody involved knows the programming
language
that is used.
> > But you do not work like that if you are involved in a large project.
> > The
> > above is true when you are writing shareware at home, drinking coke and
> > with a dirty GIF in the background. See below how real programmers do it
> > ;)
>
> Hehe, real programmers, as in m$ programmers? :)
No, as in Ericsson programmers ;)
> > No, but I got bored ;) But seriously. In a large project coding and
> > compiling is a very small part. The optimal project only needs to
> > be compiled once. That is what every software company is aiming for.
> > Unfortunately this is not possible, but if you put a lot of effort
> > into solving the problems in the early system design you will get
> > it back later.
>
> M$ does it.... One compile, ready to give away...
M$ does not run large projects, just small ones like Windows 95.
> > The typical project looks something like this:
> >
> > 55% Prest> > 10% Coding, compiling
> > 35% Test
>
> You're missing a part, the part where you evaluate the program, see if
> it's "good", and perhaps make adjustments...
True, but the adjustments is not implemented until the next project. So
the
evaluation is a part of the next prestudy ;)
/Dan
Olice Certain
No they are 'c o m p i l e d' as stated above. Of course they
are compiled. Do you use some sort of interpretive language on
your large projects?
Yes - Large projects *can* be run like that, and - yes - they are,
generally.
>/Dan
You *do not* know what you are talking about. I've worked on several
large projects. The last one just over a year ago. My part of the
project (a database analyzer) - a very small part of the project -
was compiled *many* times before it was ready for inclusion with
the main source code. You have to compile in order to debug.
In *every* large project I've worked on we combined the source for
compile many times before the project was completed in order to
submit the code to testing.
You usually have a project leader who oversees the project. When
you submit your source to the project leader it has to have been
debugged. You need to be able to demonstrate that it functions
properly. You can only do this by compiling your code, debugging
it, running it, and checking the results. You use stubs and some
sort of "front end" that supplies your code with the components
needed to complete its process.
Even after you are sure your process functions properly there is
a chance it *will not* behave properly when included in the
complete project. That is why you need to compile all the source
and test it.
In every large project I've worked on something would malfunction
when all the source was combined and compiled the first time.
That's when all the finger pointing starts - happens *every time*.
You'd better be able to demonstrate that your code did not cause
the malfunction or you're in for some long days and late nights.
Olice Certain
ocer...@webwide.net
David M. Director
Olice Certain <ocer...@no.spam.webwide.net> wrote in article
<33A7EC...@no.spam.webwide.net>...
>
> [snip]
>
> You usually have a project leader who oversees the project. When
> you submit your source to the project leader it has to have been
> debugged. You need to be able to demonstrate that it functions
> properly. You can only do this by compiling your code, debugging
> it, running it, and checking the results. You use stubs and some
> sort of "front end" that supplies your code with the components
> needed to complete its process.
>
> Even after you are sure your process functions properly there is
> a chance it *will not* behave properly when included in the
> complete project. That is why you need to compile all the source
> and test it.
>
> In every large project I've worked on something would malfunction
> when all the source was combined and compiled the first time.
> That's when all the finger pointing starts - happens *every time*.
> You'd better be able to demonstrate that your code did not cause
> the malfunction or you're in for some long days and late nights.
>
> Olice Certain
> ocer...@webwide.net
>
You're still not doing it correctly. While much of what you say is true,
you're
still missing the point -- you don't recompile the world half a dozen times
a day.
Instead, when work from several individuals is ready to be combined, it
should
be done off-line, on a separate machine, and usually is run overnight.
Testing
is then done on the entire package, by a separate testing group, and they
report
bugs back to the individual programmers. They, in turn, track down their
specific
problems (sometime creating simple "shell" routines for testing), fix and
retest their
modules separately, and forward the fixes to the testing group for re-test
during the
next cycle. This process is usually supported by some type of code
repository
such as SCCS or CVS under Unix, CMS on VAX/VMS, and a variety of others
on DOS/Windows.
If you do it this way (which is the way all *really* large systems are
built), there
is no need for an individual programmer to do large compiles on a regular
basis.
Again, however, when it's absolutely necessary, start up a big batch job
when you're
leaving for the day, and let it complete overnight.
-- David
Asbjørn
Oh, well, we learned that you have an evaluation part... Isn't that why
there's
beta's ?
Anthony Q. Bachler, BAS
Just thought I'd add my $0.02 worth here. The 286 version of Pmode is
different than the 386 on up. The 286 was still a 16 bit machine and made
no provisions for leaving Pmode once it was entered. To leave, you had to
reset the chip.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
My favorite books:
Turbo C/C++ the complete reference 0-07-881776-5
Tricks of the game programming gurus 0-672-30507-0
The 8088 and 8086 microprocessors 0-13-248337-8
PC interrupts 0-201-57797-6
Programmers technical reference 1-56276-016-5
Life, the universe, and everything ISBN unknown
The Art of War
The Prince
The Phone Book
My little black book
Asbjørn wrote in article <33A5BA...@hotmail.com>...
>Alan M. Evans wrote:
>>
>> Patrick D. Rockwell wrote:
>>
>> > I know that this is old news, but about a year ago, there was a
thread
>> > on comp.lang.pascal.borland and other newsgroups called "Write your
>> > own operating system". In one of the posts, someone posed a reason
why
>> > you might actually want an operating system that uses protected
memory
>> > as Dos does, (for reasons OTHER than maintaining backwards
>> > compatiblility) instead of just allowing the user to have FULL access
>> > to the memory as do the 32bit operating system. Dos anyone remember
>> > anything like this?
>> >
>> > As far as I know, the only reason that Dos has protected memory is so
>> > that it can be used by the 8088 microprocessor. Are there any other
>> > advantages that protected memory might confere? Thanks.
>>
>> I assume here that when you say protected memory that you are referring
>> to protected mode memory addressing. If that is the case then I think
>> you are somewhat misinformed. DOS is real mode, not protected mode, and
>> protected mode wasn't used by the 8088 processor.
>
>pmode came with the 286, and dos is pure rmode, but the user prog can
>enter
>pmode.
>
>> As far as I know, the chief advantage of protected mode is that it
>> protects different segments of memory from each other. In terms of
error
>> trapping, it is not difficult to see why this would be valuable to an
>> operating system: a program that crashes in one segment will not bring
>> the entire system down with it.
>
>But if you see how it's implemented, it often does :)
>
Anthony Q. Bachler, BAS
Sounds like you are using a single file for your program. This can easily
e avoided if you use seperately compiled module that are then linked. A
change in one module just means that its OBJ file must be recomoiled. Then
the rest of the program is just linked in.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
My favorite books:
Turbo C/C++ the complete reference 0-07-881776-5
Tricks of the game programming gurus 0-672-30507-0
The 8088 and 8086 microprocessors 0-13-248337-8
PC interrupts 0-201-57797-6
Programmers technical reference 1-56276-016-5
Life, the universe, and everything ISBN unknown
The Art of War
The Prince
The Phone Book
My little black book
Asbjørn wrote in article <33A5BF...@hotmail.com>...
>Dan Green wrote:
>>
>> Rune Moberg wrote:
>> >
>> > In article <339FE9...@krug.gsm.ericsson.se>,
>> > Dan Green <era...@krug.gsm.ericsson.se> wrote:
>> > >Why would Pascal be more stable than C? And why is compile time
>> > >a factor to consider on this matter?
>> >
>> > Pascal is way easier to read than C, thus helping maintainability
>> > and productivity.
>>
>> I disagree. I have no problems what so ever to read well structured
>> C source code.
>
>Well, that might be because you know c. I found it very hard to remeber
>all those | and % and ^. What's so wrong with or, mod and xor? And
>pointers?
>Well, I haven't got them working either. And the way you can just start
>using
>a variable anywhere in the code, it's a real pain in the ass, if you ask
>me...
>
>> > Compile time directly influences productivity. The more time you
spend
>> > compiling, the less time you get working on your code. And with C,
you
>> > definatively need more time reading/writing code! (atleast if you
>> > want to be sure that you don't make silly mistakes that a decent
Pascal
>> > compiler would catch for you)
>>
>> That is very ignorant of you. I can promise you that I write/read C
source
>> as fast as you read/write Pascal dito. It is just a matter of
>> experience.
>
>Which you gain much quicker using pascal, than c, i'm sure of...
>
>> And as I said before, the time you spend compiling is insignificant in
>> relation to the real designwork.
>
>Is it? Ok, let's say you're working on a rather large project. Let's say
>u
>use watcom, not djgpp, and borland sucks, right? :) Now, make a little,
>but
>vital change, so that you need to rebuild the program. Those things
>happen.
>15minutes later, you're ready to see if the change was good. If you'd
>used
>pascal, you could have changed/copiled/tried like three times by now.
>
>> > A Pascal coder:
>> > 1. write some code
>> > 2. compile and immediately go back to your code and make
corrections,
>> > the compiler will catch 95% of all mistakes
>> > 3. either write some _more_ code or make a small test run (old
habits
>> > die hard)
>> > 4. repeat
>> > 5. actually leave work at your convenience (8 hour day). No job
security
>> > though, because someone else will actually be able to read your
code
>> > and replace you if something happend to you.
>> > 6. spend time on the newsgroups, laughing at people that are so
>> > unfortunate that they have to work with C.
>>
>> A real software designer:
>>
>> 1. Investigates the requirements
>> 2. Divides the functionality into well defined modules
>> 3. Writes a technical solution
>> 4. Draws a flowchart
>> 5. Implements the code
>> 6. Compiles the code
>> 6.1 Corrects minor mistakes
>> 6.2 Recompiles the code
>> 7. Tests the code
>> 8. Releases the code to a happy user
>
>Wow, just two compiles, and ready to sell? Well, that doesnt' sound like
>any "real" programmer i've ever seen (or heard about). You think they
>compiled
>Quake only two times?
>
Patrick D. Rockwell
In article <33A5BA...@hotmail.com>, Asbjørn <lor...@hotmail.com> wrote:
>Alan M. Evans wrote:
>>
>> Patrick D. Rockwell wrote:
>>
>> > I know that this is old news, but about a year ago, there was a thread
>> > on comp.lang.pascal.borland and other newsgroups called "Write your
>> > own operating system". In one of the posts, someone posed a reason why
>> > you might actually want an operating system that uses protected memory
>
>enter pmode.
Ok. Well, in that case, is there a possible advantage that could be gotten
from having an operating system that is PURE real mode as Dos is besides
maintaining backwards compatibility with an old processor as Dos does for
the 8088?
--
....................Patrick D. Rockwell..................................
proc...@harp.aix.calpoly.edu
HNH...@prodigy.com
patri...@aol.com
Bevyn Douglas Quiding
In article <5o9q34$u...@harp.aix.calpoly.edu>,
proc...@harp.aix.calpoly.edu (Patrick D. Rockwell) wrote:
>
>Ok. Well, in that case, is there a possible advantage that could be gotten
>from having an operating system that is PURE real mode as Dos is besides
>maintaining backwards compatibility with an old processor as Dos does for
>the 8088?
yep you can use the bios without hacking it.
Bevyn.
--
disclaimer
not only did i not post this i have never seen any of these letters before in my life.
Guaranteed silly posts or my money back!!!
Dan Green
Olice Certain wrote:
>
> Dan Green wrote:
> >That is because your projects are compelled as stated above. Large
> >projects cannot be run like that, and they are not, generally.
>
> No they are 'c o m p i l e d' as stated above. Of course they
> are compiled. Do you use some sort of interpretive language on
> your large projects?
Oops, wrong word. I did not mean "compiled" but instead I was talking
about the way the project was divided into its different phases.
> Yes - Large projects *can* be run like that, and - yes - they are,
> generally.
No they are not.
> >/Dan
>
> You *do not* know what you are talking about.
Yes I *do*.
> I've worked on several
> large projects. The last one just over a year ago. My part of the
> project (a database analyzer) - a very small part of the project -
> was compiled *many* times before it was ready for inclusion with
> the main source code. You have to compile in order to debug.
Yes, code may be compiled several times but in relation to the other
activities it is not a major part of the development.
> In *every* large project I've worked on we combined the source for
> compile many times before the project was completed in order to
> submit the code to testing.
Perhaps, but I bet that you spent a hell of a lot more time thinking
about solutions, gathering data and coding than compiling. If not, I
think that you should start thinking about changing the way you work.
> You usually have a project leader who oversees the project. When
> you submit your source to the project leader it has to have been
> debugged. You need to be able to demonstrate that it functions
> properly. You can only do this by compiling your code, debugging
> it, running it, and checking the results. You use stubs and some
> sort of "front end" that supplies your code with the components
> needed to complete its process.
That is not a *LARGE* project. When I am talking about large projects
I refer to projects involving 50-100 programmers and thousands of mh.
In such a large project I can assure you that the project leader has
better things to do than collecting source code ;)
> Even after you are sure your process functions properly there is
> a chance it *will not* behave properly when included in the
> complete project. That is why you need to compile all the source
> and test it.
Tes.
> In every large project I've worked on something would malfunction
> when all the source was combined and compiled the first time.
Ofcourse, no large project works perfectly the first time. But the
ideal project should.
/Dan
Scott Wisniewski
> As far as I know, the chief advantage of protected mode is that it
> protects different segments of memory from each other. In terms of error
> trapping, it is not difficult to see why this would be valuable to an
> operating system: a program that crashes in one segment will not bring
> the entire system down with it.
>
The advantage of protected mode is that it allows you to get past the
640k limit of dos. Dos is protected mode. I hat to break you bubble, but
its true.
-Scott Wisniewski
Dan Hildebrand
In article <33A95255...@ruhs.uwm.edu>,
Scott Wisniewski <wi...@ruhs.uwm.edu> wrote:
>> As far as I know, the chief advantage of protected mode is that it
>> protects different segments of memory from each other. In terms of error
>> trapping, it is not difficult to see why this would be valuable to an
>> operating system: a program that crashes in one segment will not bring
>> the entire system down with it.
>
>640k limit of dos. Dos is protected mode. I hat to break you bubble, but
>its true.
More than this, it allows you to build your OS as a team of cooperating
processes, each running in their own MMU-protected address space. MUCH
more robust systems can be built this way.
--
Dan Hildebrand (da...@qnx.com) QNX Software Systems, Ltd.
http://www.qnx.com/~danh 175 Terence Matthews
phone: +1 (613) 591-0931 Kanata, Ontario, Canada
fax: +1 (613) 591-3579 K2M 1W8
Alan M. Evans
Scott Wisniewski wrote:
> The advantage of protected mode is that it allows you to get past the
> 640k limit of dos. Dos is protected mode.
That's funny.
AME
Robert Forsyth
This is a multi-part message in MIME format.
--------------5DD712B3ADF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
You can get DOS extenders, (the most famous is Windows,) there abilities
vary, but, you can get something like 4G Byte of virtual memory.
See:
Quarter Deck
Zortech C++
Pharlap
Rob.
--------------5DD712B3ADF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[Image] [Image]
[IWare Connect][Partition-It]
[CleanSweep 3.0 - with SafetySweep]
[Image]
HOME | PRODUCT INFO | SERVICE & SUPPORT | INTERNATIONAL | DOWNLOAD DEMOS
HOW TO BUY | PRESS/INVESTOR | ABOUT QUARTERDECK | OTHER SITES | SEARCH
CONTACT QUARTERDECK | EMPLOYMENT OPPORTUNITIES | SITEMAP
[Image]
© 1997 Quarterdeck Corporation. Comments to webm...@qdeck.com
[Image]All products mentioned are trademarks or registered trademarks of
their respective owners.
--------------5DD712B3ADF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[Symantec] [Product Information] [Purchase] [Service & Support] [Corporate] [Reference]
[What's Ne[Survey][Internet FastFind] [Shadow]
[SARC]
[Get it Free]
[Internet Tools]
[Press Center]
[Events Calendar]
[Shadow]
[Search][FTP][Feedback][Help]
Copyright © 1996-1997 Symantec Corporation. All rights reserved.
Last revised: June 12, 1997
--------------5DD712B3ADF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Base: "http://www.pharlap.com/"
<BASE HREF="http://www.pharlap.com/">
<HTML><HEAD><TITLE>Pharlap Software</TITLE></HEAD>
<BODY BGCOLOR=#ffffff>
<TABLE WIDTH="100%">
<TR><TD COLSPAN=3><CENTER><IMG VSPACE=10 ALIGN=RIGHT HSPACE=50 ALT=Pharlap Software SRC="logo2.gif"><BR clear=all>
<img ALIGN=RIGHT HSPACE=70 alt="The 32-bit x86 Experts" src="slogan.gif"></CENTER></TD>
<TD><A HREF="pharform.htm"><IMG BORDER=0 VSPACE=5 ALT=ETS Microweb Software SRC="epcbutton.gif"></A></TD></TR>
</TABLE>
<BR CLEAR=ALL>
<BLOCKQUOTE><FONT SIZE=2>
Phar Lap Software is a pioneer in 32-bit development tools for
the 386 processor family. Founded in 1986, Phar Lap Software
is the developer of the industry’s leading DOS extenders
as well as tools for the development of embedded and realtime
systems. More than 35,000 programmers have used Phar Lap development
tools to build and deliver over 2,500 software products. These
products include widely used 32-bit DOS software packages such
as Autodesk’s AutoCAD 386, and Microsoft’s Visual C++,
FoxPro for DOS, and PowerStation Fortran. Types of embedded applications
that have been built with Phar Lap tools include; a marine safety
system trainer, facsimile server, blood analyzer, realtime data
acquisition software, and machine control software.
</FONT SIZE></BLOCKQUOTE>
<BR CLEAR=ALL>
<center>
<NOBR>
<a href=dosexd.htm><IMG ALT="TNT DOS-Extender" SRC="btnt.gif"
border=0></a><a href=rdosxd.htm><IMG ALT="TNT Realtime DOS-Extender"
SRC="btntr.gif" border=0></a><a href=etsd.htm><IMG ALT="ETS Kernel" SRC="bets.gif"
border=0></a><a href=other.htm><IMG ALT="Other Products" SRC="bother.gif"
border=0></a><a href=techsup/tsup.htm><IMG ALT="Tech Support" SRC="btech.gif"
border=0></a><a href=about.htm><IMG ALT="Corporate Information" SRC="bci.gif"
border=0></a><a href=press.htm><IMG ALT="Press Releases" src="bpr.gif"
border=0></a> </NOBR>
<img alt="Embedded Development - Simply on Target" src="rant2.gif"><p>
<font size=2>Phar Lap Software, Inc.
<BR> 60 Aberdeen Avenue
<BR> Cambridge, MA 02138
<BR> (617) 661-1510 FAX (617) 876-2972
<BR clear=all><P></font></center>
</BODY></HTML>
--------------5DD712B3ADF--
Nobody
Anthony Q. Bachler, BAS <cwhi...@sockets.net> wrote in article
<5o0s44$8...@news.sockets.net>...
> I disagree. I find C much easier to read. I think that some C
programmers
> and some pascal programmers just write shitty to read code. Also, any
> program which is optimized will be very hard to read since the code will
be
> assuming lots of stuff and following the programmers thought pattern.
I don't know how you can find C easier to read! I'm one of those people
whose been cursed with the belief of friends and colleagues that I am a
pretty good C programmer. Yet I loathe the language. True, if it is
properly structured its not as bad as some say.
However, a well structured and properly written Pascal program is so much
simpler to understand.
Before anyone asks, yes I am biased to Pascal. It was the first language I
used commercially some 9 or 10 years ago. C did not follow until 2 years
later.
Paul W.
Asbjørn
Robert Forsyth wrote:
> You can get DOS extenders, (the most famous is Windows,) there abilities
> vary, but, you can get something like 4G Byte of virtual memory.
Just look at this... windows... extender... What's wrong? :)
Btw, with the pentium, you can get like 4Tb of total memory...
Anthony Q. Bachler, BAS
I feel the same way in reverse. I like C, but loathe to read pascal.
Perhaps it all comes down to what one is used to.
P.S. For a good laugh (if you are aware of Citizen Nudds' feeble
spoutings), see "My Analysis of Nudds" in alt.lang.asm. it also explains
my opinion in greater detail.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
My favorite books:
Turbo C/C++ the complete reference 0-07-881776-5
Tricks of the game programming gurus 0-672-30507-0
The 8088 and 8086 microprocessors 0-13-248337-8
PC interrupts 0-201-57797-6
Programmers technical reference 1-56276-016-5
Life, the universe, and everything ISBN unknown
The Art of War
The Prince
The Phone Book
My little black book
Nobody wrote in article <01bc7d81$52584120$2c0a...@P016505.logica.co.uk>..
.
Kim Robert Blix
"Alan M. Evans" <loo...@airmail.net> once said:
>Scott Wisniewski wrote:
>> The advantage of protected mode is that it allows you to get past the
>> 640k limit of dos. Dos is protected mode.
>
>That's funny.
You know whats _really_ funny? I like segments :) hehe I do. They are actually
more help to me then difficult .
>AME
--
Kim Robert Blix ( kb...@sn.no & http://home.sn.no/~kblix )
"How do you shoot the devil in the back?"
"What if you miss?" -Verbal Kint
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Patrick D. Rockwell
Robert Forsyth wrote:
>
> Alan M. Evans wrote:
> >
> >
> > > The advantage of protected mode is that it allows you to get past the
> > > 640k limit of dos. Dos is protected mode.
> >
> > That's funny.
> >
>
> You can get DOS extenders, (the most famous is Windows,) there abilities
> vary, but, you can get something like 4G Byte of virtual memory.
I know that the limit of BP7.01 is supposed to be 7.01 but can you
actually squeeze 4 GBYTES out of it using Dos xtenders/pointers/whatever
other tricks there are?
-Patrick-
Daniel Eriksson
Asbjørn wrote:
> Btw, with the pentium, you can get like 4Tb of total memory...
4TB? That would mean it has 42 address lines (4.4TB). Funny! ;-)
The Pentium has 32 address lines making it capable of addressing
4GB (4 294 967 296 bytes). Most high-end MB vendors provides for
512MB or 1GB of memory on the board.
If you're running Windows NT (<= 4) the upper half of the address
space is reserved for the OS. This gives NT a 2GB memory limit.
I leave it to someone else to explain how crap like DOS, Win3 or
Win95 deals with memory
--
Daniel Eriksson
Patrick D. Rockwell
Patrick D. Rockwell wrote:
>
> Robert Forsyth wrote:
> >
> > Alan M. Evans wrote:
> > >
> > > Scott Wisniewski wrote:
> > >
> > > > The advantage of protected mode is that it allows you to get past the
> > > > 640k limit of dos. Dos is protected mode.
> > >
> > > That's funny.
> > >
> > > AME
> >
> > You can get DOS extenders, (the most famous is Windows,) there abilities
> > vary, but, you can get something like 4G Byte of virtual memory.
>
> I know that the limit of BP7.01 is supposed to be 7.01 but can you
DAMN!!! Sorry about that. I meant to say that I know that the limit of
BP7.01 is supposed to be 16 Megs, but...
> actually squeeze 4 GBYTES out of it using Dos tenders/pointers/whatever
Matthew Vea
Daniel Eriksson wrote:
>
> Asbjørn wrote:
>
> > Btw, with the pentium, you can get like 4Tb of total memory...
>
> 4TB? That would mean it has 42 address lines (4.4TB). Funny! ;-)
Asbjorn (sorry, I don't know how to get that character between the j&r)
is right. With the processor's paging circuits enabled, you can address an
enormous amount of memory. One single page table can handle the 4BG of
physical address space, but all the page tables together can address 64
terabytes of logical memory (virtual).
"Because each task on the Military Intel486 processor has a maxiumum of 16K
(2^14-1) selectors, and offsets can be 4Gbytes (2^32 bits), this gives a
total of 2^46 bits or 64 terabytes of logical address space per task"
(Military Intel486 Processor Family #271329-003, page 56).
--
Matthew Vea
LasVegas' Domain : http://www.flash.net/~theveas/lasvegas
Domain Extension : http://lasvegas.dyn.ml.org (when I'm on-line)
Programmer's Cache : http://www.flash.net/~theveas/lasvegas/program.htm
Matthew Vea
Daniel Eriksson wrote:
>
> But it still only has 32 external address lines...
It only has to have 32 address lines. Physically, yes, the CPU can only
address 4GB. But LOGICALLY, it can handle far more than that. Go to this
address http://www.kingsnet.com/~lance/i386/manual.htm and check out the
power that even a lowly little 386 really has.
Anthony Q. Bachler, BAS
ERRRRRT. Try again! You get no more total memory on the pentium than you
do on the 486. The 4TB you are refering to is Vitual memory, which is only
theoretically possible if every process uses 4GB and you have 64K processes
going on at once which is also possible on the 486.. The physical limit is
still 4GB per process.
--
::-)
Replies to: cwhizard at vax2.rainis.net
----------------------------------------------------------------------------
---
My favorite books:
Turbo C/C++ the complete reference 0-07-881776-5
Tricks of the game programming gurus 0-672-30507-0
The 8088 and 8086 microprocessors 0-13-248337-8
PC interrupts 0-201-57797-6
Programmers technical reference 1-56276-016-5
Life, the universe, and everything ISBN unknown
The Art of War
The Prince
The Phone Book
My little black book
Asbjørn wrote in article <33AA98...@hotmail.com>...
>Robert Forsyth wrote:
>> You can get DOS extenders, (the most famous is Windows,) there
abilities
>> vary, but, you can get something like 4G Byte of virtual memory.
>
>Just look at this... windows... extender... What's wrong? :)
>
>Btw, with the pentium, you can get like 4Tb of total memory...
>
Asbjørn
Daniel Eriksson wrote:
>
> Asbjørn wrote:
>
>
>
> 4GB (4 294 967 296 bytes). Most high-end MB vendors provides for
> 512MB or 1GB of memory on the board.
> If you're running Windows NT (<= 4) the upper half of the address
> space is reserved for the OS. This gives NT a 2GB memory limit.
Hmm... ok, i though it was 4tb for some reason unknown to me :)
Prob has something to with the 4mb paging or something... Well,
4gb is so far just about enough...
Daniel Eriksson
Matthew Vea wrote:
> With the processor's paging circuits enabled, you can address an
> enormous amount of memory. One single page table can handle the 4BG
> of physical address space, but all the page tables together can
> address 64 terabytes of logical memory (virtual).
But it still only has 32 external address lines...
--
Daniel Eriksson