Steve wrote: As a side note, Cherri has explained her answer about the binary/decimal arithmetic overflow question, and I now understand what she was trying to say and agree with it. Sorry about the misunderstanding. -- Steve Heller (stheller@koyote.com), January 28, 2000.

I thought your argument re BDC versus binary arithmetic was sound - I must have missed Cherri's final answer in the debate. What was it?

-- pgmr (pgmr@pgmr.com), January 28, 2000

Answers

pgmr:

You can also see the goobly-gook answers from Poole at

Link

I am not promoting this site but Poole also discussed the answer there; whatever that is worth. Just passing on the information.

Best wishes,,,

-- Z1X4Y7 (Z1X4Y7@aol.com), January 29, 2000.

Once again, Mr. Poole CET, doesn't have a clue.

He cites smaller embedded processors. Let's take a look at the 6502 microprocessor, an older 8 bit machine.

The 6502 was introduced many years before the 8088 processor, which was used in the original IBM/PC. The 6502 was the heart of the Apple- II, the Atari-400/800 and many other "home computers" at that time. The Intel 8080, and the Zilog Z-80 were also popular at that time. Aside from "home computer" use, these were the processors used in virtually every "embedded system" at the time. You can't get much "smaller" than this.

Now, don't make me go dig up the book, from what I remember, the 6502 had a fully functional BCD mode. It had a "D" flag, and the instructions SED (Set decimal) and CLD (clear decimal). When in DECIMAL mode, the OVERFLOW flag worked just like it did in BINARY mode. If you added 99 + 1, the result was 00, and the OVERFLOW flag was set.

So once again, Mr Poole CET, is showing his age, and his experience, or lack of.

<:)=

-- Sysman (y2kboard@yahoo.com), January 29, 2000.

6502

(hardware) An eight-bit microprocessor designed by MOS Technologies around 1975 and made by Rockwell.

Unlike the Intel 8080 and its kind, the 6502 had very few registers.

It was an 8-bit processor, with 16-bit address bus. Inside was one 8-bit data register (accumulator), two 8-bit index registers and an 8-bit stack pointer (stack was preset from address 256 to 511). It used these index and stack registers effectively, with more addressing modes, including a fast zero-page mode that accessed memory locations from address 0 to 255 with an 8-bit address (it didn't have to fetch a second byte for the address).

The 6502 also had undocumented instructions.

Back when the 6502 was introduced, RAM was actually faster than CPUs, so it made sense to optimize for RAM access rather than increase the number of registers on a chip.

The 6502 was used in the BBC Microcomputer, Apple II, Commodore, Apple Computer and Atari personal computers. Steve Wozniak described it as the first chip you could get for less than a hundred dollars (actually a quarter of the 6800 price).

The 6502's indirect jump instruction, JMP (xxxx), was broken. If the address was hexadecimal xxFF, the processor would not access the address stored in xxFF and xxFF + 1, but rather xxFF and xx00. The 6510 corrected this bug.

The 65816 is an expanded version of the 6502.

There is a 6502 assembler by Doug Jones which supports macros and conditional features and can be used for linkage editing of object files. It requires Pascal.

-- Cherri (sams@brigadoon.com), January 29, 2000.

I thought your argument re BDC versus binary arithmetic was sound - I must have missed Cherri's final answer in the debate. What was it?

-- pgmr (pgmr@pgmr.com), January 28, 2000

pgmr, thats odd, I didn't know he had put up an arguement for you to agree with, he asked me a question.

-- Cherri (sams@brigadoon.com), January 29, 2000.

Here's my explanation of what Cherri was referring to when she said that binary overflow would not cause decimal overflow. Of course, if that's not what she meant, I hope she will clarify.

There are two different kinds of overflow that can occur when you add one to "99":
1. A date string that used to be two or four characters expands to three, five, or even six characters as a result of improper formatting, leading to problems like the improper representation "19100" for the year 2000.
2. Incrementing the BCD value "99", which would result in the value "00" with a carry, which may or may not be a problem.

I believe what Cherri was saying was that embedded systems would not have the first kind of overflow problem because they do not use variable length strings of the kind used in C and Java, which exhibit such problems.

This seems reasonable to me, and as I am not an embedded systems expert, I will take her word on this.

I believe that Cherri agreed on the other thread that it was possible that the second kind of overflow could occur in an embedded system, although she did not think it was likely that this could cause any serious problems.

I hope this clears up any remaining confusion.

-- Steve Heller (stheller@koyote.com), January 29, 2000.

Steve, I read the latest threads last night concerning this discussion and let me say this - I truly admire the way you have ended this. It does appear that you and Cherri were talking apples and oranges for a bit there, with most of us who aren't that knowledgable "down at the microprocessor level" trying to follow.

As for BCD, let me be the first to admit that I haven't worked with this stuff in years, I work at the "upper level" systems now, but on occassion I do get down to the "bit" level for specific devices. I flat out forgot BCD until you refreshed my memory. That leaves me out as an expert, lol.

From the "black box" level in Y2K assessments and testing, the most common results I have seen are year returns of 19100 and 1900 on screens and in printouts, and by far the problems have been minor trending screens, etc. are an exception in some cases). Of course the end results take in all of the date handling components, the microprocessor, the operating system instructions, the application program, and these address how the date is stored in memory. For lower level devices, this is all in firmware, but for complex systems, this includes software for systems with traditional computer interfaces such as MMI interfaces for data acquistion units, PLCs, and distributed control systems (DCS).

FYI, from the few number of devices I have examined at the memory storage level, most date/time stamp data was stored in registers in binary form, not BCD. I wouldn't be suprised to learn however that some lower level devices are using BCD to go to an LCD display that could display a date - the example you gave would fit this usage.

Cherri, sorry for kind of implying that you might have made a mistake in the earlier thread, although I did state in the earlier thread that you and Steve might be talking about two different things (cases), I guess I too got wrapped up in the BCD example and didn't clearly see that you were talking about the binary level handling of data.

Basically, this was a case of two people discussing a very technical subject, both of whom were right about what they were speaking, only they were talking about different cases. And again, IMHO, it is admirable of Steve to clarify this - he did not have to look beyond his BCD example, and could have stuck with that, but in the end, he chose to look at the bigger picture and do the right thing in regards to you.

As for me, I learned (and relearned) a bit from both of you, thanks.

Best wishes,

-- FactFinder (david@bzn.com), January 29, 2000.

Well Cherri, your description of the 6502 is quite accurate, right down to the JMP bug. Page zero mode was neat, but only the last 128 bytes were available to the programmer. The first 128 were reserved for the OS, at least on the Atari.

I used as assembler known as MAE (Macro Assembler/Editor) which provided features similar to what you described, but didn't require any other software (ie. Pascal).

Have a nice weekend. <:)=

-- Sysman (y2kboard@yahoo.com), January 29, 2000.

Steve Heller (stheller@koyote.com), January 29, 2000. I believe what Cherri was saying was that embedded systems would not have the first kind of overflow problem because they do not use variable length strings of the kind used in C and Java, which exhibit such problems. So Java is not used in embedded systems programming? Or even C????

Is that correct? It is the C language that has the overflow problem. If you put more digits into a storage area which is too small then it spills over to adjacent areas (which may hold critical info).

I thought many of the 19100 problems were caused because the C (and Java) year value for 2000 is 100 (not, as is often thought, 00). So if the programmer was expecting 00 and got 100 instead and only allowed for 2 digits, what happens? As far as I can tell, anything could happen.

Can anyone with hands on knowledge please confirm?

-- pgmr (pgmr@pgmr.com), January 29, 2000.

I don't think the language matters. And I don't think the BCD example is really what it's about, although that does serve as a good example of overflow.

What does matter is how a language displays a field. Maybe a better way of saying it: what is the "default edit pattern" of a language? Just about every language allows you to edit a field when you display it. The PIC clause of Cobol, the FORMAT statement in Fortran, or the ED instruction in big iror assembly. But most languages also allow you to display a field with NO editing, or formating. Many just chop off the leading zeros, and "display" the result. But there is no standard for the default. It even varies from compiler to compiler, for the same language.

A 1 byte binary field can contain an unsigned value from 0 thru 255, so it could take from 1 to 3 bytes to display. And if it's a signed field, up to 4 bytes (you need a place for the - sign).

Does this help? <:)=

-- Sysman (y2kboard@yahoo.com), January 29, 2000.

PS - And by "display" I don't mean only limited to a crt or paper. What I do mean is what happens when a field is moved, and or converted, or otherwise operated on. <:)=

-- Sysman (y2kboard@yahoo.com), January 29, 2000.

Sysman (y2kboard@yahoo.com), January 29, 2000 wrote:

The PIC clause of Cobol, the FORMAT statement in Fortran, or the ED instruction in big iror assembly. But most languages also allow you to display a field with NO editing, or formating. Many just chop off the leading zeros, and "display" the result. But there is no standard for the default. It even varies from compiler to compiler, for the same language.

A 1 byte binary field can contain an unsigned value rom 0 thru 255, so it could take from 1 to 3 bytes to display. And if it's a signed field, up to 4 bytes (you need a place for the - sign).

Yes, we know how much a one byte binary field can contain but we are talking about BCD. You referred to COBOL so lets go with that.

If you have a working storage field: YY PIC XX and you place a value of 100 into it, what happens? It gets 'chopped' right. My memory is rusty as its been 20 years since I wrote COBOL so I couldn't tell you how it gets chopped but I do know that only that field is affected - it does not 'overflow' into other fields unless they are subsidiary - in this intance there is no subsidiary fields. The C language is different. Putting 100 into a 2 byte BCD field will cause corruption of any adjoining byte(s?). This byte could contain something critical to the operation of the device. So, a programmer who wrongly thinks the C language tm_year value will always return a 2 digit value could easily place this value into a 2 byte field for display or for calculation purposes. This may cause a problem which maybe minor but maybe minor. Right?

COBOL does not have the year 2000 = 100 problem so a programmer is unlikely to place that value into YY - the C language, however, does.

Does this help? <:)=

--

-- pgmr (pgmr@pgmr.com), January 29, 2000.

Oops, Freudian slip? Should read:

This may cause a problem which maybe minor but maybe major . Right?

-- pgmr (pgmr@pgmr.com), January 29, 2000.

I believe the apples and oranges analogy was correct. I appreciate Steve honestly explaining that he came to understand what I was trying to say. Unfortunatly I am not good at explaining what I am thinking.

it was important to me to clarify that I could not give a cut and dried answer because the answer depended on how the system was set up to function under those conditions.

If it was set up to disallow incrimenting after binary 1001 (disabling the 2 and 4 digits (with an "anded" 8 and 1 digit) (not allowing 1010 or "a" hex) then the possibility of what would be displayed depends on how it is designed to display. This may or may not be known to the programmer. The same routine that stops the incriment at 9 may also set a flag which denotes ??? user defined action. Overflow, stop, anything is possible, that is the problem, you have to see the design and read the schematic or pinout to learn what is supposed to happen.

My origional point was to explain that all functions are done in binary by the machine, no matter how they are set up to work or be seen by us.

As in BCD

1001=9

add

0001 the results will be 1010 or the results may be prevented from incrimenting to 1010 and an error, or overflow bit may be set or not. What ever it does is by design, the actual function is done on a binary leval and at a binary leval an overflow in decimal does not cause an overflow in binary. The logic may be set up to show an overflow at the decimal (or BCD or whatever) leval, but "logically" under normal conditions, it will not.

AARRGG! I know what I am trying to say.. *grin* but I don't believe I am showing it clearly enough for others to understand.

This is the reason, though, that the people who were looking into potential problems in embeddeds from Y2K needed to be able to understand digital logic and unfortunatly I do not believe that many who worked on them did.

This is why I said embeddeds could be checked at the schematic leval without being tested physically. The logic can show how they would respond to certain inputs, removing the need to physically "test" them.

-- Cherri (sams@brigadoon.com), January 29, 2000.

So, Cherri, embedded systems can have 'overflow' problems?

Please give a straight answer without getting technical.

-- pgmr (pgmr@pgmr.com), January 29, 2000.

Sorry gang, I had to logon with work for a while, then went to the IRS site to figure where I stand for last year. Those bastards!

Anyway pgmr,

Yes, overflow is always a problem, minor or major. All I'm saying is that it can occur in any language, on any platform. Let's stick with Cobol.

Your example uses PIC XX for the receiving field, and truncation would occur. But numbers are defined using PIC 99... Numeric truncation in controlled by the TRUNC compiler option. You can read about TRUNC in the IBM Online Library. I took VSE Cobol because that's what I work with. You can check the OS/390 link at the bottom of the page, but I'm sure it has similar options.

Now, most good cobol programmers use COMP (binary) for numeric fields, because binary math is faster than packed-decimal, and MUCH faster that unpacked decimal. So it wouldn't be uncommon to see the following in a Cobol program:

01 DATE COMP.

05 MM PIC 99.

05 DD PIC 99.

05 YY PIC 99.

Many shops, mine included, use TRUNC(BIN) as the default, because:

"TRUNC(BIN) is the recommended option when interfacing with other products that have System/370 format binary data (such as CICS, FORTRAN, and PLI). This is particularly true if there is a possibility of having more than 9 digits in a fullword, or more than 4 digits in a halfword."

This is our system default. Some shops run with NOTRUNC, which is very similar to TRUNC(BIN). If you look at the example, you will see that even though a field is defined as PIC 9(6), you can DISPLAY a field with a much larger value, 1234567891 in the example.

So if we wrote the following one year ago:

DISPLAY MM "/" DD "/" YY.

The result would be 1/29/99

Now let's say your driver's license is up for renewal. The wise-guy programmer says this is easy, I'll just:

ADD 1 TO YY.

But now, the same DISPLAY would be:

01/29/100

Does that help?

<:)=

-- Sysman (y2kboard@yahoo.com), January 29, 2000.

Oops, I didn't drop the leading 0. The "correct" result would be:

1/29/100

Tick... Tock... <:00= ...

-- Sysman (y2kboard@yahoo.com), January 29, 2000.

I only used COBOL as a way of explaining that truncation can occur when programming - the fact that computers use binary does not automatically preclude this. Yes, maybe programmers should always use 'comp' which is the binary methos of holding numeric values but often (very often!) they don't.

Having shown that truncation can occur, my next point is that in the C programming language, overflow occurs, not truncation. The C programming language can be used to programm embedded systems and overflow can cause serious problems if data overflows on to other values and corrupts them. In such cases, the device could either freeze or cause a value to give an incorrect reading. C gives 100 for year 2000 not 00 - therefore there is every likelihood that the space set aside for the YY value could overflow.

Do we have any C programmers here? Better still, do we have any embedded systems programmers who program in C and could they comment? What language do you use Cherri?

-- pgmr (pgmr@pgmr.com), January 29, 2000.

OK pgmr,

I think we're on the same page. Overflow/truncation can occur anywhere, in any language, IMHO. If you really want the details on C, I hope someone does check in. I've played with it, but am far from an expert. Funny, I have Visual Studio 6 on this machine, but I just can't get away from my old friend, ASSEMBLY!

Someday, right before I concentrate on Java...

See ya! <:)=

-- Sysman (y2kboard@yahoo.com), January 30, 2000.

As far as I am able to research, overflow only occurs in C.

If you are going to tackle Java - good luck! Who ever invented that must have been a masochistic C programmer. I liken Java devotees (as apart from those forced to learn and use it) to those who prefer the Bible to be in Latin rather than English - only for the truly initiated, not for the average programmer who just wants to get something useful to the user. But then to a certain degree, that's what the technical community prefers anyway. OO is great though!

-- pgmr (pgmr@pgmr.com), January 30, 2000.

As far as I am able to research, overflow only occurs in C.

No, ASCII overflow (the "19100" and "192000" problems) will occur anytime that the programmer misunderstands the operation of the function that he is calling to get the year part of a date. One of these functions returns the following sequence of years:

98
99
100

If a programmer believes that this function returns the last two digits of the year, rather than the actual value, which is the year minus 1900, and also doesn't realize that his program will stop working correctly after 1999, he may prefix the output result with the literal value "19", resulting in the following output sequence:

1998
1999
19100

Another possibility that I have seen in a utility program I've had for many years, is the following sequence of year numbers:

98
99
2000

This could lead to a similar problem to the above, except that the resulting "years" would be:

1998
1999
192000

By the way, I have a lot of trouble believing that there isn't a lot of this garbage working its way into databases and spreadsheets all over the world at this moment.

-- Steve Heller (stheller@koyote.com), January 30, 2000.

Steve When I refer to overflow, I'm not talking about year 2000 giving 100 - this can happen in any programming language but particularly Perl, Java and C where the actual language value for Year 2000 is 100 (it is in fact the number of years since 1900???? - a very bad design decision as it is fraught amiguity)

When I referred to overflow it was the problem that occurs with C when you stuff too much info into a filed and it spills out all over whatever is sitting next door and can really screw things up. That is stick 100 into a 2 digit only filed and the extra digit will end up next door which could be the storage for anything that the program is using. Nasty but true. I wish a C programmer was in the vicinity to comment on the likelihood of this happening with the tm_year value of 100 being placed into a storage area that is too small for it.

-- pgmr (pgmr@pgmr.com), January 30, 2000.

Hey pgmr,

I still think that we're, almost, still on the same page, but what is this all about:

"As far as I am able to research, overflow only occurs in C"

Sheesh man, I just gave you an example, with a link to the IBM Library, where they show you how an "overflow" is possible in Cobol.

Are you going to make me go dig up an example in Fortran? How about Assembly? Go ahead, make my day .....

Like I said, I hope that a C guy does show up here. But as for this "only in C" crap, give it up! Overflow and/or (?) truncation, can, and does, occur in EVERY (haven't found one yet) language. You pick. Overflow, or truncation? There is no standard... !!!

Say what?

Tick... huh?... Tock... <:00= ...

-- Sysman (y2kboard@yahoo.com), January 31, 2000.

Sysman, I believe you and pgmr are talking golden delicious and granny smith (at least both are apples).

pgmr's asking specifically about the situation where the operating system (or whatever watches over this stuff) may refrain from protecting the memory set aside for one operand, from being written to insidiously by part of an entirely separate operand. To apply this to your COBOL example, it would be as if the "0" that was truncated from "01/31/100" was instead written to memory that did not "belong" to that date field.

I don't think pgmr is disputing that if your result won't fit into the alloted space, something has to give; he's just asking about that one particularly scary case of overflow.

-- David L (bumpkin@dnet.net), January 31, 2000.

I guess we are talking at cross-purposes - computer technology seems to have a lot of this.

My definitions of truncation and overflow are not one and the same. Truncation happens in any language when a value is 'chopped' because there is not enough room to hold the complete value. The bytes chopped are lost/trashed and do not cause a problem. The truncated vale may still cause a problem but that is not what I'm talking about.

Overflow is the same except that the bytes chopped are not lost - they overwrite the adjacent storage area.

I found an interesting item today while trying to get more info on softeare overflow. It appears to be an overflow problem occurring in ADA - although I need to re-read it again to verify this. Still, it makes for interesting reading if you are of a technical bent.

http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

It starts ...

On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded. Engineers from the Ariane 5 project teams of CNES and Industry immediately started to investigate the failure. Over the following days, the Director General of ESA and the Chairman of CNES set up an independent Inquiry Board ...

-- pgmr (pgmr@pgmr.com), January 31, 2000.