posted 07-13-99 09:49 AM ET            

Dim reply as integer
IF Reply = 0 then
frm2.show
Else if
frm3.show
endif
end sub

posted 07-13-99 11:16 AM ET            

// Don't know why this works, but it does...so I left it in

posted 07-13-99 11:19 AM ET         

Creators Admit Unix and C Language Hoax

In an announcement that stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted the Unix operating system and C programming language created by them is an elaborate prank, kept alive over 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following:

"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had started work with an early release of Pascal from Professor Niklaus Wirth's ETH labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading 'Bored of the Rings', a National Lampoon parody of the Tolkien's 'Lord of the Rings' trilogy.

As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new OS to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. We sold the terse command language to novitiates by telling them that it saved them typing."

Then Dennis and Brian worked on a warped version of Pascal, called 'A'. 'A' looked a lot like Pascal, but elevated the notion of the direct memory address (which Wirth had banished) to the central concept of the language. This was Dennis's contribution, and he in fact coined the term "pointer" as an innocuous sounding name for a truly malevolent construct.

Brian must be credited with the idea of having absolutely no standard I/O specification: this ensured that at least 50% of the typical commercial program would have to be recoded when changing hardware platforms. Brian was also responsible for pitching this lack of I/O as a feature: it allowed us to describe the language as "truly portable".

When we found others were actually creating real programs with A, we removed compulsory type-checking on function arguments. Later, we added a notion we called "casting": this allowed the programmer to treat an integer as though it were a 50k user-defined structure. When we found that some programmers were simply not using pointers, we eliminated the ability to pass structures to functions, enforcing their use in even the Simplest applications.

We sold this, and many other features, as enhancements to the efficiency of the language. In this way, our prank evolved into B, BCPL, and finally C. We stopped when we got a clean compile on the following syntax:

for (;P("\n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("|"+(*u/4)%2);

At one time, we joked about selling this to the Soviets to set their computer science progress back 20 or more years. Unfortunately, AT&T and other US corporations actually began using Unix and C. We decided we'd better keep mum, assuming it was just a passing phase. In fact, it's taken US companies over 20 years to develop enough expertise to generate useful applications using this 1960's technological parody.

We are impressed with the tenacity of the general Unix and C programmer. In fact, Brian, Dennis and I have never ourselves attempted to write a commercial application in this environment. We feel really guilty about the chaos, confusion and truly awesome programming projects that have resulted from our silly prank so long ago."

Dennis Ritchie said: "What really tore it (just when AIDA was catching on), was that Bjarne Stroustrup caught onto our joke. He extended it to further parody, Smalltalk. Like us, he was caught by surprise when nobody laughed. So he added multiple inheritance, virtual base classes, and later ... templates. All to no avail. So we now have compilers that can compile 100,000 lines per second, but need to process header files for 25 minutes before they get to the meat of "Hello, World".

Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused to comment on the announcement. Officials of Borland International, a leading vendor of object-oriented tools, including Turbo Pascal and Borland C++, stated they suspected this for a couple of years.

In fact, the notoriously late Quattro Pro for Windows was originally written in C++. Borland CEO Del Yocam said: "I'm told that, after two and a half years of programming, and massive programmer burn-out, we recoded the whole thing in Turbo Pascal in three months. It's fair to say that Turbo Pascal saved our bacon back then". Another Borland spokesman said that they would continue to enhance their Pascal products, and halt further efforts to develop C/C++.

posted 07-13-99 11:25 AM ET         

I will kill you and eat your bones...*
No, on second thought I will let you live and make you work with undocumented OOP code forever. Buwhahahahahahaha...

posted 07-13-99 12:22 PM ET            

A recent article devoted to the macho side of programming made the bald and unvarnished statement:
                                          Real Programmers write in FORTRAN.
Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN.  Not RATFOR.  Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
                                      Directly.
Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.
I first met Mel when I went to work for Royal McBee Computer Corp.,
a now-defunct subsidiary of the typewriter company.
The firm manufactured the LGP-30,
a small, cheap (by the standards of the day)
drum-memory computer,
and had just started to manufacture
the RPC-4000, a much-improved,
bigger, better, faster -- drum-memory computer.
Cores cost too much,
and weren't here to stay, anyway.
(That's why you haven't heard of the company,
or the computer.)
I had been hired to write a FORTRAN compiler
for this new marvel and Mel was my guide to its wonders.
Mel didn't approve of compilers.
"If a program can't rewrite its own code",
he asked, "what good is it?"
Mel had written,
in hexadecimal,
the most popular computer program the company owned.
It ran on the LGP-30
and played blackjack with potential customers
at computer shows.
Its effect was always dramatic.
The LGP-30 booth was packed at every show,
and the IBM salesmen stood around
talking to each other.
Whether or not this actually sold computers
was a question we never discussed.
Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port?  What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.
In modern parlance,
every single instruction was followed by a GO TO!
Put that in Pascal's pipe and smoke it.
Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the "read head"
and available for immediate execution.
There was a program to do that job,
an "optimizing assembler",
but Mel refused to use it.
"You never know where it's going to put things",
he explained, "so you'd have to use separate constants".
It was a long time before I understood that remark.
Since Mel knew the numerical value
of every operation code,
and assigned his own drum addresses,
every instruction he wrote could also be considered
a numerical constant.
He could pick up an earlier "add" instruction, say,
and multiply by it,
if it had the right numeric value.
His code was not easy for someone else to modify.
I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the "top-down" method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.
Mel never wrote time-delay loops, either,
even when the balky Flexowriter
required a delay between output characters to work right.
He just located instructions on the drum
so each successive one was just past the read head
when it was needed;
the drum had to execute another complete revolution
to find the next instruction.
He coined an unforgettable term for this procedure.
Although "optimum" is an absolute term,
like "unique", it became common verbal practice
to make it relative:
"not quite optimum" or "less optimum"
or "not very optimum".
Mel called the maximum time-delay locations
the "most pessimum".
After he finished the blackjack program
and got it to run
("Even the initializer is optimized",
he said proudly),
he got a Change Request from the sales department.
The program used an elegant (optimized)
random number generator
to shuffle the "cards" and deal from the "deck",
and some of the salesmen felt it was too fair,
since sometimes the customers lost.
They wanted Mel to modify the program
so, at the setting of a sense switch on the console,
they could change the odds and let the customer win.
Mel balked.
He felt this was patently dishonest,
which it was,
and that it impinged on his personal integrity as a programmer,
which it did,
so he refused to do it.
The Head Salesman talked to Mel,
as did the Big Boss and, at the boss's urging,
a few Fellow Programmers.
Mel finally gave in and wrote the code,
but he got the test backwards,
and, when the sense switch was turned on,
the program would cheat, winning every time.
Mel was delighted with this,
claiming his subconscious was uncontrollably ethical,
and adamantly refused to fix it.
After Mel had left the company for greener pa$ture$,
the Big Boss asked me to look at the code
and see if I could find the test and reverse it.
Somewhat reluctantly, I agreed to look.
Tracking Mel's code was a real adventure.
I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.
Perhaps my greatest shock came
when I found an innocent loop that had no test in it.
No test.  None.
Common sense said it had to be a closed loop,
where the program would circle, forever, endlessly.
Program control passed right through it, however,
and safely out the other side.
It took me two weeks to figure it out.
The RPC-4000 computer had a really modern facility
called an index register.
It allowed the programmer to write a program loop
that used an indexed instruction inside;
each time through,
the number in the index register
was added to the address of that instruction,
so it would refer
to the next datum in a series.
He had only to increment the index register
each time through.
Mel never used it.
                                      Instead, he would pull the instruction into a machine register,
add one to its address,
and store it back.
He would then execute the modified instruction
right from the register.
The loop was written so this additional execution time
was taken into account ---
just as this instruction finished,
the next one was right under the drum's read head,
ready to go.
But the loop had no test in it.
The vital clue came when I noticed
the index register bit,
the bit that lay between the address
and the operation code in the instruction word,
was turned on ---
yet Mel never used the index register,
leaving it zero all the time.
When the light went on it nearly blinded me.
He had located the data he was working on
near the top of memory ---
the largest locations the instructions could address ---
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.
I haven't kept in touch with Mel,
so I don't know if he ever gave in to the flood of
change that has washed over programming techniques
since those long-gone days.
I like to think he didn't.
In any event,
I was impressed enough that I quit looking for the
offending test,
telling the Big Boss I couldn't find it.
He didn't seem surprised.
When I left the company,
the blackjack program would still cheat
if you turned on the right sense switch,
and I think that's how it should be.
I didn't feel comfortable
hacking up the code of a Real Programmer.

posted 07-14-99 02:41 AM ET            

Actually, I tryed to learn C++, but without books (which are extremley expencive here in Croatia) I only spend time for nothing.

posted 07-14-99 03:39 AM ET            

AND DEFINATLY REAL PROGRAMMERS DONT USE

VISUAL BASIC - ONLY USED FOR DIRE EMERGENCIES

c++ ONLY USED FOR THICK PROGRAMMERS

JAVA wANKERS ONLY

----------------------

PROGRAMMERS THE REAL TYPE WHICH I CONSIDER MYSELF TO BE

NEVER EVER EVER COMMENT THEIR CODE

P.S. WHO IS THAT GEEKS PICTURE ON THE MIRC START UP FORM

AND IF U DONT KNOW WHAT A FORM IS GET LOST

SORRY ABOUT THE CAPS

posted 07-14-99 04:55 AM ET            

Where is the logic in this.....
i know the entire ASCII code table yet i sometimes forget my wife's name... anybody had anysimmilar experinces let me know

You been waiting for them i have come up with a set of Rules to become a REAL PROPER PROGRAMMER:

Real Programmers aren't afraid to use GOTO's

Real Programmers can write 5 page long DO loops without getting confused

Real Programmers like arithmetic IF statements -- they make the code more interesting

Real Programmers write self-modifying code, especially if it can save 20 nanoseconds in the middle of a tight loop

Real Programmers don't know their wives's name; they do know, however, the entire ASCII code table

Real Programmers don't write specs. Users should consider themselves lucky to get any programs at all and take what they get

Real Programmers don't comment their code. If it was hard to write, it should be hard to read

Real Programmer's programs never work the first time. But if you throw it into the machine, it can be made to work in "only a few" 30-hour sessions

Real Programmers don't write in Pascal, COBOL, Ada or any of those pinko computer science languages. Strong typing is for people with weak memories

Real Programmers think structured programming is a communist plot

Real Programmers don't use APL, unless the whole program can be written on one line

Real Programmers like vending machine popcorn. Coders pop it in the microwave; Real Programmers use the heat given off by the CPU. They can tell what job is running by listening to the rate of popping

Real Programmers only use a Direct Memory Editor to build a program. They only use an assembler if they wrote themselves

Real Programmers don't work 9 to 5. If any Real Programmer is around at 9 AM, it's because he was up all night

Real Programmers never get annoyed by security systems; they turn off the RACF bits and leave unsigned messages in the security data sets

Real Programmers don't know how to cook. Grocery stores are not open at 3 AM. They survive on twinkies and coffee

posted 07-14-99 09:06 AM ET            

always trying to shave them few last nanoseconds

i long for the good old days

Remember BASIC

posted 07-14-99 01:17 PM ET            

Pascal:
"The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the 'standard procedures'. The language is closed...I feel that it is a mistake to use Pascal for anything much beyond its original target. In its pure form, Pascal is a toy language, suitable for teaching but not for real programming." -- Brian Kernighan

----
MangoBreeder:

"Real Programmers don't write in Pascal, COBOL, Ada or any of those pinko computer science languages."

With the possible exception of Real Programmers using ADA at the DoD.

posted 07-14-99 01:21 PM ET            

I was never that dedicated, but I remember watching people at University bootstrapping the PDP 11 by toggling the bootstrap routine on the front panel ... from memory. Many's the long hour I spent punching cards, and tape, however!

Spoe:

Spent quite a few hours in the lab watching people write drum and core access routines. I never could see the point myself. Most of the time I was there I spent wishing I'd gone to a software University, rather than Manchester, but when I started work I got 5% higher salary than any other graduate, and I found that I was still using principles that I was taught there 10 and 15 years later.

Ah, the good old days.

posted 07-15-99 05:44 AM ET            

WHO Agrees: Strctured Programming Is a communist plot...

and whats up with the 4gen prog. langs.

**** i actually have to goto work

posted 07-15-99 07:14 AM ET         

Re: Counting clock cycles; I said that it was fun then.

posted 07-16-99 03:32 AM ET         

Real Programmers don't write on PL/I Pl/I is for programmers who can't decide wheter to write in COBOL or FORTRAN

Real Programmers don't read manuals. Reliance on a reference is a hallmark of a novice and a coward

Real programmers don't document. Documentation is for wimps who cant read listngs of the core dumps

Real Programmers know what the users need better than the users

Real Programmers don't use LISP. Only effeminate programmers use more parentheses than actual code

Real Programmers scorn Floating point arithmertic. the decimal point was invented fo pansy betwetter who are unable to think big

Real Programmers Know every nuance of every instruction and use them all in every real program. Puppy architects won't alloe execute instructions to address another execute as the target instruction. Real Programmers dispise such petty restrictions

posted 07-16-99 04:07 AM ET            

Program CRC;

{ CRC generation program, version 7b (optimized + timing + documentation)

This set of implementations was written by Me (Andrew Mangion), and
has been placed in the public domain, to be used at the user's
discretion.

This program demonstrates various ways by which Cyclic
Redundancy Checks (CRC) may be computed and their relative speeds.

Please note the cautionary notice involving the routine SET_TIMER.
This routine should be used only by users who understand its
consequences and who wish to experiment with interrupt and timer
routines. The routine has been written for use on an IBM PC or
compatible.

The variable TIME is the location of the low 16 bits of the TIMER
location incremented by DOS 2.0 with each clock tick. It is defined
in the source code for the IBM PC ROM BIOS. This should work with
most compatibles as well as later versions of the operating system.

Here are some sample results. These were obtained using TURBO 3.0
under DOS 2.0 on a SEEQUA Chameleon. (Your mileage may vary.)
(Note that the CRC is printed to assure that all implementations
are working properly.)

D a t a S t r e a m L e n g t h

512 1024 2048 4096 32767

No table 0.33 0.65 1.31 2.62 20.93 CRC = -31717
Nybble table 0.10 0.18 0.38 0.76 6.03 CRC = -31717
Two Nybble tables 0.10 0.18 0.36 0.74 5.88 CRC = -31717
Byte table 0.08 0.16 0.32 0.64 5.12 CRC = -31717
Nybble string 0.03 0.05 0.09 0.18 1.50 CRC = -31717
Byte string 0.01 0.03 0.05 0.09 0.73 CRC = -31717

}

Const
max = 32767;

Type
Bytes = Array [1..max] of Byte;

Var
time : Integer Absolute $0040:$006c; { TIMER_LOW
IBM PC ROM BIOS location }

initial_clock, stop, j, i : Integer;

length : Array [1..5] of Integer;

table_16 : Array [0..15] of Integer;
table_32a : Array [0..16] of Integer;
table_32b : Array [0..16] of Integer;
table_256 : Array [0 .. 255] of Integer;

CRC_value : Integer;

byte_string : Bytes;

POLY : Integer;

{
CRC polynomials in this program are represented by replacing
each term that is non-zero with a 1 and each zero term with a 0.
Note that the highest order bits represent the low order terms
of the polynomial.

Thus X^3+X^1+1 becomes 1101 and X^4+X^1+1 becomes 11001.

Since all polynomials have a highest term (X^a) we drop the
highest term during computation (shift right one bit).

Here are some examples :

Polynomial Representation Hex

X^5 + X^2 + 1 10100 $14

X^7 + 1 1000000 $40

X^3+X^2+X^1+1 111 $7

X^6+X^5+X^3+1 100101 $25

For a good discussion of polynomial selection see "Cyclic
Codes for Error Detection", by W. W. Peterson and
D. T. Brown, Proceedings of the IEEE, volume 49, pp 228-235,
January 1961.

A reference on table driven CRC computation is "A Cyclic
Redundancy Checking (CRC) Algorithm" by A. B. Marton and
T. K. Frambs, The Honeywell Computer Journal, volume 5,
number 3, 1971.

Also used to prepare these examples was "Computer Networks",
by Andrew S. Tanenbaum, Prentice Hall, Inc. Englewood Cliffs,
New Jersey, 1981.

The following three polynomials are international standards:

CRC-12 = X^12 + X^11 + X^3 + X^2 + X^1 + 1
CRC-16 = X^16 + X^15 + X^2 + 1
CRC-CCITT = X^16 + X^12 + X^5 + 1

In Binary and hexadecimal :

Binary Hex

CRC-12 = 1111 0000 0001 $0F01
CRC-16 = 1010 0000 0000 0001 $A001
CRC-CCITT = 1000 0100 0000 1000 $8404 (Used below)

The first is used with 6-bit characters and the second two
with 8-bit characters. All of the above will detect any
odd number of errors. The second two will catch all 16-bit
bursts, a high percentage of 17-bit bursts (~99.997%) and
also a large percentage of 18-bit or larger bursts (~99.998%).
The paper mentioned above (Peterson and Brown) discusses how
to compute the statistics presented which have been quoted
from Tanenbaum.

(A burst of length N is defined a sequence of N bits, where
the first and last bits are incorrect and the bits in the
middle are any possible combination of correct and incorrect.
See the paper by Peterson and Brown for more information)

Note that when using a polynomial of degree N, the CRC is the
first N bits of the value returned by the routines below.
(e.g. with CRC-12, the CRC is bits 0 to 11 of the CRC value,
with the other two mentioned above, the CRC is all 16 bits.)

Here is a quick idea of what is being calculated ...

The CRC is the residual from division of the data stream by
the CRC polynomial. The data stream is also thought of as a
polynomial, with the highest order term being the lowest bit
of the first byte of the data stream and the lowest order term
of the polynomial being the high bit of the last byte of data.
The actual division is performed on the data stream polynomial
multiplied by X^y where y is the degree of the CRC polynomial.

CRC use ...

The CRC is then appended to the end of the data stream. When
the receiver gets the data stream, the CRC is again computed
and matched against the received CRC, if the two do not match
then an error has most likely occurred.

}

{

This work was prompted by a submission by David Kirschbaum,
who unknowingly submitted a program that contained an error.
I have not determined if what it computed has any reliable
error-detecting capabilities, only that it was an attempt to
compute a CRC, that really did not work. The original code
is correctly used in the program KERMIT (Columbia University)
to compute the CRC-CCITT polynomial CRC.

My address is

David Dantowitz
Digital Equipment Corporation
Dantowitz%eagle1.dec@decwrl

The views and ideas expressed here are my own and do not necessarily
reflect those of the Digital Equipment Corporation.

David Kirschbaum
Toad Hall
[email protected]
}

Procedure set_timer(count : Integer);

{
This routine sets the clock (timer) count-down value to
count. The DOS value is 0 (this is the maximum value ...
it really means 65536). This routine is used to obtain
better resolution in timing.

WARNING : The setting of count to too small a value will
HANG your system. Please study interrupts in
real time systems before using this routine.

WARNING : This routine was written to run on an IBM PC or
compatible. Disable this routine when this
program is run on other machines.
}

Begin

inline($b0/$36/ { mov al,36 }
$e6/$43/ { out 43,al }
$8b/$86/count/ { mov ax,bp[count] }
$e6/$40/ { out 40,al }
$88/$e0/ { mov al,ah }
$e6/$40); { out 40,al }

End;

Procedure simple_crc(b:byte);

{
This routine computes the CRC value bit by bit. The initial value
is assumed to be in a global variable CRC_value and the global variable
POLY contains the representation of the polynomial be used. The routine
is called for each byte. The result is placed in the global CRC_value.
}

Var
i : Integer;

Begin
CRC_value := b xor CRC_value;

For i := 1 to 8 Do
Begin
If (CRC_value and 1) = 1
then CRC_value := (CRC_value shr 1) xor POLY
else CRC_value := CRC_value shr 1;
End;

End;

Procedure generate_table_16(POLY : Integer);

{
This routine computes the remainder values of 0 through 15 divided
by the polynomial represented by POLY. These values are placed in a
table and used to compute the CRC of a block of data efficiently.

This implementation only permits polynomials up to degree 16.
}

Var
val, i, result : Integer;

Begin
For val := 0 to 15 Do
Begin
result := val;
For i := 1 to 4 Do
Begin
If (result and 1) = 1
then result := (result shr 1) xor POLY
else result := result shr 1;
End;

table_16[val] := result;
End
End;

Procedure generate_table_32(POLY : Integer);

{
This routine computes the remainder values of 0 through 15 divided
by the polynomial represented by POLY. These values are placed in two
tables and used to compute the CRC of a block of data efficiently.

This implementation only permits polynomials up to degree 16.
}

Var
val, i, result, divide : Integer;

Begin
{
Table_32a divides the number for eight bits (not four).
Note that Table_32b is identical to Table_16.
}

For val := 0 to 15 Do
Begin
result := val;
For i := 1 to 4 Do
Begin
If (result and 1) = 1
then result := (result shr 1) xor POLY
else result := result shr 1;
End;

table_32b[val] := result;
End;

For val := 0 to 15 Do
Begin
result := table_32b[val];
For i := 1 to 4 Do
Begin
If (result and 1) = 1
then result := (result shr 1) xor POLY
else result := result shr 1;
End;

table_32a[val] := result;
End;

End;

Procedure generate_table_256(POLY : Integer);

{
This routine computes the remainder values of 0 through 255 divided
by the polynomial represented by POLY. These values are placed in a
table and used to compute the CRC of a block of data efficiently.
More space is used, but the CRC computation will be faster.

This implementation only permits polynomials up to degree 16.
}

Var
val, i, result, divide : Integer;

Begin
For val := 0 to 255 Do
Begin
result := val;
For i := 1 to 8 Do
Begin
If (result and 1) = 1
then result := (result shr 1) xor POLY
else result := result shr 1;
End;

table_256[val] := result;
End
End;

Procedure Compute_crc_16(next_byte : byte);

{
This routine calculates the CRC and stores the result in a global
variable CRC_value. You must first initialize CRC_value to 0 or the
proper initial value for the CRC and then call this routine with
each byte.

This routine uses table_16.

}

Begin

inline(
$8b/$16/CRC_value/ {mov dx,CRC_value }
$32/$56/$be/table_16/ {mov si,offset table_16 (table address) }
$30/$ff/ {xor bh,bh (bh <- 0) }

$88/$d3/ {mov bl,dl }
$80/$e3/$0f/ {and bl,0f }
$d0/$e3/ {shl bl,1 }
$b1/$04/ {mov cl,4 }
$d3/$ea/ {shr dx,cl }
$33/$10/ {xor dx,[bx+si] CRC = (CRC shr 4) XOR
table[CRC and 0F] }

$88/$d3/ {mov bl,dl }
$80/$e3/$0f/ {and bl,0f }
$d0/$e3/ {shl bl,1 }
$b1/$04/ {mov cl,4 }
$d3/$ea/ {shr dx,cl }
$33/$10/ {xor dx,[bx+si] CRC = (CRC shr 4) XOR
table[CRC and 0F] }

$89/$16/CRC_value); {mov CRC_value,dx Update CRC in memory }

{ basic algorithm expressed above

temp := crc XOR next_byte;

For i := 1 to 2 Do
temp := (temp shr 4) XOR table [temp and $0F];

CRC_value := temp;
}
End;

Procedure Compute_crc_32(next_byte : byte);
{
This is the algorithm used in KERMIT and attempted by the routine
DoCRC from Toad Hall.

The code here completely new. This routine uses table_32a and
table_32b.
}

Begin

inline(
$8b/$16/CRC_value/ {mov dx,CRC_value }

$32/$56/{ intermediate steps, see comments for overall effect }

$31/$db/ {xor bx,bx (bx <- 0) }
$86/$d3/ {xchg bl,dl (bx <- dx and 0FF) }
$86/$f2/ {xchg dl,dh (dx <- dx shr 8) }

$88/$d8/ {mov al,bl }
$80/$e3/$0f/ {and bl,0fh }
$d0/$e3/ {shl bl,1 (bx <- bx+bx) }
$be/table_32a/ {mov si,offset table_32a (table address) }
$33/$10/ {xor dx,[bx+si] }

$88/$c3/ {mov bl,al }
$80/$e3/$f0/ {and bl,0f0h }
$b1/$03/ {mov cl,3 }
$d2/$eb/ {shr bl,cl }
$be/table_32b/ {mov si,offset table_32b (table address) }
$33/$10/ {xor dx,[bx+si] }

$89/$16/CRC_value); {mov CRC_value,dx Update CRC in memory }
End;

Procedure Compute_crc_256(next_byte : byte);

{
This routine calculates the CRC and stores the result in a global
variable CRC_value. You must first initialize CRC_value to 0 or the
proper initial value for the CRC and then call this routine with
each byte.

This routine uses table_256.
}

Begin

inline(
$8b/$16/CRC_value/ {mov dx,CRC_value }
$be/table_256/ {mov si,offset table_256 (table address) }

$32/$56/{ intermediate steps, see comments for overall effect }

$31/$db/ {xor bx,bx (bx <- 0) }
$86/$d3/ {xchg bl,dl (bx <- dx and 0FF) }
$86/$f2/ {xchg dl,dh (dx <- dx shr 8) }
$d1/$e3/ {shl bx,1 (bx <- bx+bx) }
$33/$10/ {xor dx,[bx+si] CRC = (CRC shr 8) XOR
table[CRC and 0FF] }

$89/$16/CRC_value); {mov CRC_value,dx Update CRC in memory }

{ basic algorithm expressed above

temp := crc XOR next_byte;

temp := (temp shr 8) XOR table_256 [temp and $FF];

CRC_value := temp;
}
End;

Function crc_string_16(Var s : Bytes; length, initial_crc : Integer) : Integer;

{
This routine computes the CRC value and returns it as the function
value. The routine takes an array of Bytes, a length and an initial
value for the CRC. The routine requires that a table of 16 values
be set up by a previous call to Generate_table_16.

This routine uses table_16.
}

Begin

inline(

$c4/$7e/$8b/$46/$8b/$56/$be/table_16/ {mov si,offset table_16 (table address) }
$30/$ff/ {xor bh,bh (bh <- 0) }

{ next: }

$26/$32/$05/ {xor al,es:[di] CRC = CRC XOR next byte }
$47/ {inc di (point to next byte) }

$88/$c3/ {mov bl,al }
$80/$e3/$0f/ {and bl,0f }
$d0/$e3/ {shl bl,1 }
$b1/$04/ {mov cl,4 }
$d3/$e8/ {shr ax,cl }
$33/$00/ {xor ax,[bx+si] CRC = (CRC shr 4) XOR
table[CRC and 0F] }

$88/$c3/ {mov bl,al }
$80/$e3/$0f/ {and bl,0f }
$d0/$e3/ {shl bl,1 }
$b1/$04/ {mov cl,4 }
$d3/$e8/ {shr ax,cl }
$33/$00/ {xor ax,[bx+si] CRC = (CRC shr 4) XOR
table[CRC and 0F] }

$4a/ {dec dx (count <- count -1) }
$75/$df/ {jnz next }

$89/$46/{ basic algorithm expressed above

temp := initial_crc;

For each byte Do

Begin
temp := temp XOR next_byte;

For i := 1 to 2 Do
temp := (temp shr 4) XOR table [temp and $0F];
End;

Crc_string_16 := temp;
}

End;

Function crc_string_256(Var s : Bytes; length, initial_crc : Integer) : Integer;

{
This routine computes the CRC value and returns it as the function
value. The routine takes an array of Bytes, a length and an initial
value for the CRC. The routine requires that a table of 256 values
be set up by a previous call to Generate_table_256.

This routine uses table_256.
}

Begin

inline(

$c4/$7e/$8b/$46/$8b/$4e/$be/table_256/ {mov si,offset table_256 (table address) }

{ next: }

$26/$32/$05/ {xor al,es:[di] CRC = CRC XOR next byte }
$47/ {inc di (point to next byte) }

{ intermediate steps, see comments for overall effect }

$31/$db/ {xor bx,bx (bx <- 0) }
$86/$d8/ {xchg al,bl (bx <- ax and 0FF) }
$86/$e0/ {xchg al,ah (ax <- ax shr 8) }
$d1/$e3/ {shl bx,1 (bx <- bx+bx) }

$33/$00/ {xor ax,[bx+si] CRC = (CRC shr 8) XOR
table[CRC and 0FF] }

$e2/$f0/ {loop next (count <- count -1) }

$89/$46/
{ basic algorithm expressed above

crc := initial_crc

For each byte Do
Begin
crc := crc XOR next_byte;

crc := (crc shr 8) XOR table_256 [crc and $FF];
End;

crc_string_256 := crc;
}
End;

Begin

Writeln('Generating the data string, please wait ...');
Writeln;
Writeln;

Generate_table_16($8404);
Generate_table_32($8404);
Generate_table_256($8404);

For j := 1 to max Do
byte_string[j] := trunc(random*256); { Create a data string }

length[1] := 512;
length[2] := 1024;
length[3] := 2048;
length[4] := 4096;
length[5] := 32767;

Writeln;
Writeln(' D a t a S t r e a m L e n g t h');
Writeln;
Write(' ');

For j := 1 to 5 Do
Write(' ', length[j]:8);

Writeln;
Writeln;

Initial_clock := time;

Set_timer(5964); { each tick = ~0.005 seconds }

{-----------------------------------------------------------------------------}

CRC_value := 0;
POLY := $8404;

Write('No table ');

For j := 1 to 5 Do
Begin
time := 0;
For i := 1 to length[j] Do
simple_crc(byte_string[i]);
stop := time;
Write(stop/200:5:2, ' ');
End;

Writeln('CRC = ', CRC_value);

{-----------------------------------------------------------------------------}

CRC_value := 0;

Write('Nybble table ');

For j := 1 to 5 Do
Begin
time := 0;
For i := 1 to length[j] Do
compute_crc_16(byte_string[i]);
stop := time;
Write(stop/200:5:2, ' ');
End;

Writeln('CRC = ', CRC_value);

{-----------------------------------------------------------------------------}

CRC_value := 0;

Write('Two Nybble tables ');

For j := 1 to 5 Do
Begin
time := 0;
For i := 1 to length[j] Do
compute_crc_32(byte_string[i]);
stop := time;
Write(stop/200:5:2, ' ');
End;

Writeln('CRC = ', CRC_value);

{-----------------------------------------------------------------------------}

CRC_value := 0;

Write('Byte table ');

For j := 1 to 5 Do
Begin
time := 0;
For i := 1 to length[j] Do
compute_crc_256(byte_string[i]);
stop := time;
Write(stop/200:5:2, ' ');
End;

Writeln('CRC = ', CRC_value);

{-----------------------------------------------------------------------------}

CRC_value := 0;

Write('Nybble string ');

For j := 1 to 5 Do
Begin
time := 0;
CRC_value := crc_string_16(byte_string, length[j], CRC_value);
stop := time;
Write(stop/200:5:2, ' ');
End;

Writeln('CRC = ', CRC_value);

{-----------------------------------------------------------------------------}

CRC_value := 0;

Write('Byte string ');

For j := 1 to 5 Do
Begin
time := 0;
CRC_value := crc_string_256(byte_string, length[j], CRC_value);
stop := time;
Write(stop/200:5:2, ' ');
End;

Writeln('CRC = ', CRC_value);

{-----------------------------------------------------------------------------}

set_timer(0); { restore the clock to the normal DOS value }

time := initial_clock; { we may have lost a few minutes ... }