• (nodebb)

This may actually be the frist NWTF in here.

• Old Fart (unregistered)

So this is basically a Fortran representation of De Morgan's Theorem?

• WTFGuy (unregistered)

Following the link to the PAL24 assembler I was impressed with how nice the FORTRAN was. Consistent naming, good use of comments, intelligent use of formatting, etc. Logically it looks a bit like gobbledygook, but a) FORTRAN is like that, and b) I know zero about programming PALs.

For awhile I was responsible for about 12K lines of FORTRAN written by a series of structural engineering PhDs. I still get the shakes thinking about fixing the unholy mess they'd made.

• Foo AKA Fooo (unregistered) in reply to Old Fart

Nope, DeMorgan would turn in into:

LSAME = ((LOUTP(IOUTP)).AND.(LPHAS1(IOUTP)) .OR. .NOT.(.LOUTP(IOUTP)).OR.(LPHAS1(IOUTP)) ) )

This actually takes one gate fewer. I guess that's TWRTF here, wasting a precious gate!

• CrashMagnet (unregistered)

I was struck by two thoughts after looking at the program.

First, how tight and neat the formatting was. Somebody spent a lot of time getting that program to look that good.

Second, there is an enormous amount of white space in the header. In this program the name of the program starts in column 2, while comments start in column 24. The mindset for formatting the code carried over to formation the comments. It's beautify, but the guy wasted a lot of space.

• (nodebb)

The logical operator for that I believe is .EQV.

• (nodebb) in reply to Foo AKA Fooo

Might it be important how large the gates are? NOT gates are smaller than their multi-input siblings, so it might be possible to cram the one from the post into a smaller physical space. I don't know though, I've never used a PAL.

• I dunno LOL ¯\(°_o)/¯ (unregistered)

I think I've seen this code before. And I decided it was easier to just write my own from scratch. But it helped that these days there's only three types that matter: 16V8, 20V8 and 22V10, even if you have deal with three different chip modes for each one. Holy crap the plethora of PAL types there used to be, and they're not even erasable. Thank you Lattice.

• doubtingposter (unregistered) in reply to nerd4sale

We've had several entries on the friday image posts that should really have been submitted to TheDailyGoodPractice.com

But it may be the first article post.

• BeenHereSeenThat (unregistered)

Youngings should listen to their Elders. Fortran was punched on cards.
Columns mattered. Each character was a precious byte of memory. Source was printed and managed on green bar paper. It was a different world then.

Or so my Elders inform me.

• Just another Embedded Designer (unregistered)

Saying "PAL’s were an early form of programmable ROM,"

Is more akin to saying an x86 processor was an early form of memory stick. As both have some form of memory in them even if only registers.

Yes PALs (and PLA's, later PLD and FPGA) all have gates (AND, OR, NOT, sometimes XOR) in them with many gates have two outputs for AND and NAND output paths to link. But VERY quickly they had registers (D, JK, T and others) as well as more complex dedicated logic.

The only part that was close to a ROM was the fusemap for the thousands of interconnect "links"

Thank you AMD, Signetics, Motorola (whatever name changes now), Philip/NXP (and other name changes), Xilinx, Altera and many other names

• markm (unregistered) in reply to Sulis

It encodes Not Exclusive-Or, which for boolean values is the equivalent of Equal. PAL's generally did not have Exclusive-Or gates. In fact, the ones I remember had only wide-input NAND gates, in two levels, which is the equivalent of ANDs followed by OR. So you reduced everything to the form A&&B || C&&D

• quasiCoder (unregistered)

More NWTF's please. While it's fun to look and laugh at what goes wrong, it is nice to see good practice sometimes; even better if it's not apparent at first.

• dumbApe (unregistered)

it is a good lesson for all programmers who think they know better than other programmers. too often programmers are quick to accuse someone of bad code when it is often that they simply do not have the full story and there is a darn good reason for for it. this happens often when automating office applications and you have to work around the weird behavior you find in those applications... another time I recall having to consume a corporate middleware web service that was wrapping a soap message and passing that to another web service, of course both were written in different versions of java and different versions of soap and I was accessing it from a vb.net client. the things I had to do to get that thing to work. we implemented a nice solution, but less-experienced people who looked at it at first glance thought we were needlessly adding complexity and custom classes when we could have just used a framework class.... and they were paid to do a code analysis they were clearly unqualified to do.

• Anon E. Mouse (unregistered) in reply to BeenHereSeenThat

Yeah, but a SMART person could program the card punch with a control card that implemented one touch skip to a specific column.

http://www.columbia.edu/cu/computinghistory/029.html

• Bill T (unregistered) in reply to CrashMagnet

Usually programs need to be written for humans to read. In this case, it needs to be written for the PAL to read.

The author managed to do both at the same time. Incredible.

• John R. Strohm (unregistered) in reply to Foo AKA Fooo

The catch is that PALs do not permit arbitrary logic expressions. They require the lowest layer to be AND expressions, with or without inverters (NOT). The first layer is programmable. The second layer must be OR expressions, and the exact nature of those expressions is fixed by the PAL manufacturer. Different PALs have different OR-networks.

Yes, application of DeMorgan's Theorem would simplify the result, but the result in this particular case would not be implementable on a PAL.

Guys who are used to chip design languages (VHDL, Verilog) or any of the myriad PLD languages are also used to thinking of everything happening at once - since on the chip all the gates are running all the time, massively parallel.

So they often have real problems coming over to normal programming where only one thing is happening at a time. Though they will pick up parallelism easier than most. But they won't get locks because in CDL/PLD-land you control things with timing and signals, and latches are considered Bad (simplified). And VHDL/Verilog are so damn ugly they end up writing really ugly C, where you get unnecessary chip-isms being used in normal code where they're not required like this one.

Of course that's a generalization, I did know a couple who were perfectly fine in Verilog or C.

• Olivier (unregistered)

PAL is as much like ROM as the gas tank of your car is like the steering wheel. It has been almost 40 years since I used PAL, but I do remember it is not some memory, it is not there to store data but is it an array of logical gates: you send several digital signals in the input and receive digital signals at the output. And what is done to the input signals is programmable (but only once).

I don't remember how I programmed the PAls I used, but certainly not in Fortran as the system only had assembly.

• (nodebb) in reply to Olivier

So you stored a program in it?

In any version of Fortran released in the last 30 years it is sensible to use the == operator instead of the antiquated .EQ. as it is just so much more readable, especially to anyone used to another language.

Almost all Fortran compilers that I've used would have show an error if you use .EQ. (or ==) between two items of type LOGICAL, so it's hard to believe this got through to production code. The correct operator, as someone else already posted is .EQV.

So there were lots of things wrong here.

• (nodebb)

I've just registered http://thedailynwtf.com/ ... you can buy it from me to cover my admin costs

Nah ... we don't need another site.

Lots of other WTFs over the years on TheDailyWTF are in fact NWTFs, but those programmers critiquing the work only have the perspective of the current code, and not the history behind it, and don't know the constraints under which development has taken place. Often work of juniors is criticised, or work of workers from other fields who dare venture into "computer science".