Programming in assembler?

You actually highlight one of the problems - a *decent* compiler. In embedded real time applications its not uncommon for the tool chain to lag behind the state of the art by quite some distance. Coupled with often massively smaller user bases for the tools, you quite often find compilers that are a tad buggy and not all that sophisticated. Hence the small number of occasions where some hand written assembler may play a part.

;-)

Even if you don't need to write it, being able to read and understand a disassembly when captured or traced via an in circuit emulator, or inverse assembled by a logic analyser can be a very useful skill.

That is merely a superficial position. Perhapsd a little more informed than most, in that it identifies a deeper unknown than is espoused by warmists, but lacking in the real analysis of all the data that is the hallmark of most intelligent climate sceptics, who are not that way because their jobs or careers depend upon it, or because they are in 'the pay of big oil and the Koch brothers' but are simply people who have been concerned enough to fully acquaint themselves with all the evidence, and follow the reaosoning, or lack of ot.

For sure. But the jury came back several years ago. CAGW depends on positive feedback, positive feedback which would have to reveal itself as tropical hot spots. No such hotspots have ever been indentified. Ergo the positive feedback does not exist. Without it CO2 induced warming is lost in the noise of other climate effects.

As shown by 20 years of no *significant* warming despite rising CO2 levels.

All real climate scientists are aware the hypothesis is refuted, and are simply split between those whose funding depends on it, who continue to find excuses, and those whose funding does not, who are distancing themselves, mouths stapled shut, as far from it as they can.

If wishes were horses beggars would ride.

WEll exactly, and trthat was where I came in to 'climate change', looking at energy. There is of course well proven non fossil technology that is far far cheaper and less troublesome and less environmentally impactful than 'renewable' energy and that is of course nuclear.

If Climate change were a serious threat, people would have been legislating to throw in nuclear power against the wishes of residents, like they do with wind power. The fact that they didn't shows they are not in the least bit worried about climate change caused bu CO2 emissions.

Germany's Energiewiende has made a lot of money for certain energy companies, at the consumers expense, has ruined the landscape of Germany, but has not result in Germany emitting any less CO2 than it di

They are in it to make money and polit8ical capital and exercsie more political control through another convenient lie.

Massive state bureaucracies need to constantly invent problems - preferably ones they cannot solve, but can make political capital out of virtue signalling, to ensure their survival.

Of course as evinced by the global economic crisis, and the global migration crisis, they are completely unable to deal with a real iworld problem when it does arrive. After all, they are not managers or technocrats, just showmen. In the vernacular. Clowns.

Donald Trump at least doesn't insult my intelligence by pretending otherwise.

Well its a clear case of GIGO. Base computer models on false and provably false assumptions, and you will get rubbish answers.

You dont need a supercomputer to predict te climate in ten years time. 3 lines of code and a random number generator in a RPi will give you a better answer than any that come out of the supercomputers.

The world is not soluble linear partial differential equations. Lots of it is a LOT more complicated than that.

And treatng it as if it isn't, simply because those are the only sorts of equations for which solutions exist, is - frankly - pathetic.

Perhaps - but that does not address the first question to be answered namely "Is the planet getting warmer ?". If it is, and the cause is not CO2 then we may have a real problem that nobody is looking at or we may just be in for a warm spell.

Perhaps - but notice the dependency on models in this argument.

Hmm 20 years is a *very* short period of time for climate trends, even the century or so of direct data is shorter than the resolution of the techniques used for the long term pictures. We have no idea how significant trends on the scale of decades are really.

The short answer is 'it was in jerky steps since the LIA ended, but now it has mostly stopped'.

WEll that is the point. Models with positive feedback are what produce the scare, and the models are clearly wrong.

Well I totally agree with you, especially since the 'evidence' for CAGW was based on less than 20 years of warming.

'warmestyear on record' means bugger all when we dont have reliable data at all, let alone going back more than a 100 years.

Howbver we can say taht iceland grew grain and supported cattle when the vikings lived there. It doesn't today very much at all.

When 'melting glaciers' uncover trees stumps in the ground, that show that the glaciers have been a whole lot smaller in the past. thats another data point.

AS is te one tree sample in the Yamal tree data that led to the infamous 'hockey stick'..

On 22/09/2016 17:03, The Natural Philosopher wrote: [snip]

ic over a

Right, this has nothing to do with ARM assembler or the Raspberry Pi, please take the discussion elsewhere.

---druck

It was a random .sig, but the -- got accidentally deleted.

On Thu, 22 Sep 2016 22:53:37 -0000 (UTC), Martin Gregorie declaimed the following:

I suspect the point was that C can directly manage memory-mapped I/O registers. Intel instruction sets included a separate range of I/O ports which were NOT accessed as memory addresses.

byte = *(0xFEEDBEEF);

to get to a memory mapped address in C. Can't do that with an Intel I/O port except via machine-code insertion.

Indeed. Martin doesn't seem to understand hardware at all.

There are, likewise, no C language constructs for disable or enable interrupts, or execute a soft interrupt (another Intel special) or move the processor in or out of any of the various modes its has.

The C library mechanism is flexible enough to allow such things to be coded in assembler and *called* from C, but they cannot be *written* in C.

And that was really all I had to say. Others have claimed that application programming need never to be done in assembler. They may be right, but the hard core of operating system work has to be. Because the higher level languages lack the necessary hardware abstractions.

It is interesting that you refer to the history of this debate. It has been going on for at least as long as I can remember. In fact, I am pretty sure the same argument was had around the first Fortran compiler back around the 1950s.

Over the years I've seen lots of what you might call "hand waving" where people who are influenced by those who write compilers say that the compiler can do a better job than a human. IME that's often true for large modules simply because of the complexity of the code.

But in just about every digestible case I've looked at, the human did better.

I would suggest two reasons:

1. Many compilers are not very good at optimising. Even the ones which are do not get to an optimal solution because of the interaction of the later stages of a compiler: instruction selection, instruction scheduling, and register allocation. There is no algorithm to get those all to work together to produce ideal results. Instead, compilers use heuristics which give a correct and pretty good result.
2. The second reason is that HLL programmers often know a lot more about what they are trying to achieve than the language they are programming in will allow them to express. The source code then becomes a broadened approximation of what the program is to do. The compiler, in turn, can only compile the source. It cannot know everything the programmer knew. So the compiled machine code becomes more bloated than that which a programmer could have written in assembly.

That's very true. For some time now, CPUs have been executing instructions out of sequence, albeit that they have to continue to retire them in sequence.

As well as data dependencies, some operations take longer so a compiler and a low level programmer will try to schedule those operations early.

As I said before, I am not against compilers. The beauty of a compiler is that it can produce code which is optimised individually for many different CPUs. (Not that that's always done. Often, a compiler will output some generic machine code that will work on any similar CPU but won't be optimised for any of them.)

HLL code is nearly always much faster to develop in. So unless there's a real need for speed then HLL development makes more sense.

By HLLs, here, I mean low level HLLs! Not all HLLs. Some of them are intrinsically very slow.

Nor have I but I am sure you are right that simpler CPUs would be much easier for a human or a compiler to optimise for.

No, not wrong. All good points IMO.

When I studied compilers I found it fascinating how a clever compiler can effectively mash up the code to make it into something which is unrecognisable but still correct. When looking at stuff like that one can easily be persuaded that the compiler is doing things that are beyond the ability of humans and it therefore must do a better job. But, at least for smaller modules, that's not how it works out in practice.

As an example, a compiler can transform source code into lots of small operations. It can then reorder those operations based on data dependencies, and convert the result to machine code. That may sound good but such an approach can dramatically increase register pressure and lead to the register allocator having to add instructions to shuffle values between registers and memory, thereby making the code slower!

For sure there's plenty of good evidence that it has at times been both warmer and colder than it is today and that historically the variations have been within quite tight bounds around the freezing point of water (at least since the first rains settled). Given the amount of water around and the energy involved in its phase changes that's not too surprising, there ought to be another very stable point around a hundred degrees higher but so far the place hasn't been hot enough to reach that one since it first cooled down.

Personally I very much doubt that it can be made to reach the high one again but I certainly don't claim to know one way or the other.

It has to do with an older usenet tradition: trolling.

By rising to the bait they've made The Natural Philosopher very happy.

No they haven't. As I said that was simply a rolling .sig file that got its leading characters deleted.

-- ?it should be clear by now to everyone that activist environmentalism (or environmental activism) is becoming a general ideology about humans, about their freedom, about the relationship between the individual and the state, and about the manipulation of people under the guise of a 'noble' idea. It is not an honest pursuit of 'sustainable development,' a matter of elementary environmental protection, or a search for rational mechanisms designed to achieve a healthy environment. Yet things do occur that make you shake your head and remind yourself that you live neither in Joseph Stalin?s Communist era, nor in the Orwellian utopia of 1984.?

Vaclav Klaus

What do they do for an encore, a ZGREATty?

One of my jobs was assembler programming for a custom DSP for which there was no higher level language. Custom hardware is getting more common, whether an application specific processor, co-processor or even FPGA for hardware-on-the-fly. As mentioned earlier on this thread, this article notes how even the new Apple phones are depending on hardware for specific tasks such as security

Most CPUs until the 80s were simple:

- opcode fetch & decode

- execute

- repeat

Then instruction pre-fetch, cache, pipelining and such moved on-chip, making it harder to track things cycle-by-cycle.

Around 1989, I had a wonderful "Introduction to RISC" course while at Concurrent Computer Corp. It was quite the culture shock for software & hardware engineers to convert from CISC to RISC. With the alleged Reduced Instruction Set Complexity, some chips had so few instructions that assembler coding had very little to gain. Our palette of expression was gone. No more looking up "the exact best instruction" on the reference card. No more fun addressing modes such as indirect addressing. That's why Freescale's ColdFire is nowhere the fun of the Motorola 68000.

The thing I found the most disturbing was the way even the assembler was subject to reordering for things like filling the delayed-jump-slot (making use of the instruction AFTER the jump/skip since it was already fetched, decoded and ready to execute). And the assembler was free to implement workarounds for errata, so what you write is NOT what you get :-0

I'm unsure there's any way to integrate feedback from execution profiling to re-optimize the program for things like cache line alignment of frequently used sections [a vague reference to "Mel, A Real Programmer" and the way drum-based systems allowed for optimizing or de-optimizing the execution time of each instruction based on the rotational latency/delay for each argument]. Large chips such as Pentium use "dynamic exploitation of parallelism" to profile the code as it's running for branch prediction, caching decoded instructions and such. But that's all second-guessing the intention of the program and trying to predict the future.

On larger chips, not the 8/16 bit microcontrollers (Atmel AVR, Microchip PIC-16/18/24, TI MSP430). But they're catching up.

Most "C" compilers now have .asm to inject inline assembler instructions, and inline functions so there's no calling-sequence overhead. My Unix driver for the 8530 SDLC serial chip was completely in "C". Only the Sun4m variation required a magic .asm to flush the write buffer.

-- jeffj

You cant really write in C completely for hardware and interrupt handling.

Even if the assembler is 'hidden' from you by #asm or by a library function.

At some level you have to read and write IO ports, and thats not a construct native to 'C' and nor is the ability to respond to a hardware interrupt.

True but that doesn't stop you writing drivers in C when the OS provides the very low level access.

Which it usually is in portable OS code, there's a great incentive in portable OS code to minimise the assembler content.