Do you consider writing this program a bit of a challenge?

[sysprog]

You forgot self-modifying code. That was the best!

Oh yes, I once encountered a page of Cobol dense with the infamous ”alter goto”, which did just what the name suggests. No comments or doc of any kind, of course.

$\dots$ lest we forget $\dots$

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

ref: http://homepages.inf.ed.ac.uk/rni/papers/realprg.html

 

[PeterDonis]

saves only a little bit of a resource there is plenty of

Even now there are still some systems (such as embedded systems) where memory is not such a resource. Also, if you're creating a large enough number of objects of some type, saving just a few bytes of memory per object can add up.

 

[Ibix]

Oh yes, I once encountered a page of Cobol dense with the infamous ”alter goto”, which did just what the name suggests. No comments or doc of any kind, of course.

I had to look that up, because I didn't believe it did what I thought it did. It did. It's not quite as bad as INTERCAL's COME FROM operation, but that language is meant to be a joke.

 

[PeterDonis]

I once encountered a page of Cobol dense with the infamous ”alter goto”, which did just what the name suggests.

This makes me glad that I've never had to program in Cobol.

 

[sysprog]

I had to look that up, because I didn't believe it did what I thought it did. It did. It's not quite as bad as INTERCAL's COME FROM operation, but that language is meant to be a joke.

INTERCAL is funny -- using PLEASE DO NOT IGNORE COME FROM risks an error for overpolteness $\dots$

 

[sysprog]

This makes me glad that I've never had to program in Cobol.

That was dropped in '85.

 

[Vanadium 50]

Even now there are still some systems (such as embedded systems) where memory is not such a resource.

Well, I might argue that this is not a good reason to avoid C++ strings in favor of C strings. It might be a good reason to avoid C++ in favor of C.

However, embedded systems aren't what they used to be. The Broadcom SOC chip used for the Raspberry Pi Zero can't cost more than a buck or two and it has 512K of memory. My thermostat runs unix for heaven's sake!

As fas as the in-memory swap, I can't imagine any modern compiler not assigning the temp variable to a register. You don't really save the memory because it was never used in the first place.

I'll concede that we can find an edge case where using C-strings over std::string can make sense. (I'm not sure the answer is "overhead in a zillion objects", though) But I think it is far more likely that edge case involves legacy code than saving one byte out of thousands.

 

[phinds]

You forgot self-modifying code. That was the best!

Yeah, I remember once when I was in my early days at NASA my boss and I had to write code to capture digital telemetry data, massage it, and transfer it to digital tape. After a fair amount of refinement we got it down to about 130% of real-time. Problem was, the data didn't care about us, it was going to come in at real-time whether we could capture it or not. So we resorted to program self modification at the machine level (assembly language). and FINALLY got it down just below 100% which at first had not seemed possible.

 

[anorlunda]

If we're thinking of small resources like embedded systems, don't forget that the use of an OS and a high level language that brings in libraries, adds far more overhead than the differences between tight versus sloppy coding.

In some cases, we opt out of both OS and high level languages to work with a bare machine. In other cases, we might use a frugal environment such as Forth.

Just slightly before my time: Around 1964, GE successfully implemented closed loop digital boiler control for a power plant in Huntington Beach California. The computer had 3 words of 24 bits each to work with. The rest resided on the drum memory.

 

[sysprog]

For those who care: https://www.intel.com/content/dam/w...4-ia-32-architectures-optimization-manual.pdf

 

[Vanadium 50]

One issue with optimization is that today's CPUs are so complex it's possible to outclever yourself while attempting to outclever them. I remember a poster session where a grad student explained that she had cleverly optimized her code for the CPU (I think it was a KNL) causing it to do more work in less time. That in turn generated more heat. That in turn caused the CPU to throttle its clock.

The net effect was no effect.

 

[sysprog]

I actually met Gene Amdahl as a young man. Twice, in fact. Spooky smart.

I posted this about 5 years ago on a Police forum:

Mainframe Pioneer Gene Amdahl Passes On at Age 92
11-16-2015, 05:19 AM

It was a few days ago but I just found out about it.

http://nytimes.com/2015/11/13/techno...?_r=0&referer=

I worked as a Systems Engineer for Amdahl Corp..
I wept on learning of his passing.
He was a great man.

Every day the Police use technology he played crucial roles in
conceiving, designing, and developing over a span of decades.

The next few times you run anyone's name through NLETS or NCIC,
or any mainframe-based system, please think of Gene Amdahl.

RIP Mr. Gene Amdahl Sir -- your great work still works -- God bless you and yours.

 

[harborsparrow]

"Do it without a temp variable". Somewhere I've seen it. Something like this?

x = 3;
y = 4;
x = x + y; // x now is 7
y = x - y; // y now is 3
x = x - y; // x now is 4

But IMO it is not reasonable to ask all students to come up with this. Only a few will be able to, and I only because I saw it done by a student once.

 

[phinds]

But IMO it is not reasonable to ask all students to come up with this. Only a few will be able to, and I only because I saw it done by a student once.

Does that include having seen @Vanadium 50 do it in post #29 ?

 

[harborsparrow]

Does that include having seen @Vanadium 50 do it in post #29 ?

Oops! Missed that. And the reason for preferring XOR. Doh!