Electronics advances.

[adrianh]

Well, if there is a storm, for example...

Interesting. My AM radio totally loses its mind and my analog phone blows up when static electricity is induced onto the line....ok, so how is that stable?

[Brett Nortje]

Interesting. My AM radio totally loses its mind and my analog phone blows up when static electricity is induced onto the line....ok, so how is that stable?

It is often more stable than a digital one. i have this thing about 'digital devices' that don't read when you want them to.

[Brett Nortje]

In electronics, a multiplexer (or mux) is a device that selects one of several analog or digital input signals and forwards the selected input into a single line.[1] A multiplexer of 2n inputs has n select lines, which are used to select which input line to send to the output.[2] Multiplexers are mainly used to increase the amount of data that can be sent over the network within a certain amount of time and bandwidth.[1] A multiplexer is also called a data selector.

An electronic multiplexer makes it possible for several signals to share one device or resource, for example one A/D converter or one communication line, instead of having one device per input signal.

Conversely, a demultiplexer (or demux) is a device taking a single input signal and selecting one of many data-output-lines, which is connected to the single input. A multiplexer is often used with a complementary demultiplexer on the receiving end.[1]

An electronic multiplexer can be considered as a multiple-input, single-output switch, and a demultiplexer as a single-input, multiple-output switch.[3] The schematic symbol for a multiplexer is an isosceles trapezoid with the longer parallel side containing the input pins and the short parallel side containing the output pin.[4] The schematic on the right shows a 2-to-1 multiplexer on the left and an equivalent switch on the right. The sel wire connects the desired input to the output.

So, it is like a switchboard for a company. this is like a modem, which is a modulator demodulator. so, it encodes and then decodes the message or signal. or, if you are an engineer, you will observe the likeness between this and a circuit, yes?

Now, to skip all this encoding then decoding, we could send the message as is through the 'switchboard.' this could be done by observing, once again, a binary circuit. what a load! i hate binary, don't you?

If you want to have faster connections you need to integrate or merge the whole thing. this can be done by using different signals electrically instead of using a physical connection. this is like holding hands in class when you sing, basically you will only be able to hold one hand with your hand, and you need to change to reconnect with someone else, or, a monkey swinging in the trees - he can only hold one thing at a time, yes?

So, you need to merge the whole circuit into a single 'transmission line.' one long cord for all messages means that the signal will go all over the place, but, only certain things react to the message. it is like telling a ice cream salesman to sell you whipped cream - he simply doesn't do anything! the ice cream man will help you though, and this will not affect the rest of the circuit, but, it uses binary, so, it might trigger something else. i suggest fully charged electrical surges.

[Justloadit]

It is often more stable than a digital one. i have this thing about 'digital devices' that don't read when you want them to.

Incorrect, the reason for the failure is due to poor software programming/techniques.

From my experience, these high level languages are to make a programmers life easy, however they introduce much much more "Noise/Clutter" into a software routine. The library routines are made to attempt to take into consideration, every conceivable solution to a library call. By doing this, the programs become so large, that they get lost, and hence the blue screen, or a static screen or where the device simply does not respond to a users input/request. The other reason, is that modern programmers have no clue how the hardware works, and simply program away to get something to market as soon as is possible, with out doing a thou rough check, and leave it to the user to find the bugs and report it to the programmer. When writing in assembler, you have to really know your nuts and bolts, and tend to test the programs for almost all types of eventualities. I even go so far as doing EMI surge noise testing, because this is what causes the micros to go astray. Remembering that a code word cause the micro to perform a task a, and by changing a single bit will cause the micro to perform task B, it simply shows that the micro no longer follows the flow of code that was written. This single bit or multiple bit changes happens with EMI pulses and surges on the line. A good well writen program will pick up that the program is going the incorrect path, and will allow the WDT to reset the processor and recover the data that it was working with, check the integrity of the data, and continue the program from where it went hay wire.

I will give you an example. I have a product, in which my last software update was done in 2000, it uses an 8 bit microprocessor, and uses 2K of program space in which I used assembler. Built into this program is a device called a "Watch Dog Timer", which basically means that routines must run with in a time frame, or else the processor will be reset, and the program starts again. This is to prevent the program from getting stuck/hanging somewhere The trick is to make the reset of the program totally transparent to the user, and the machine under control. In the high level languages this is practically impossible, because the high level language adds into your program a bunch of so called housekeeping routines which must first run when a processor is reset, making the seamless recovery very difficult, and require the programmer to make work arounds to attempt to get somewhere near where the program was when it was reset by the watch dog timer.

In this program I have a built in 32bit multiplier and divider, which does a 3rd order polynomial. If I attempt rewrite the program in a higher level language, such as 'C', I will need a minimum of 16K of program.
I am unfortunately moving away from assembler, simply because I can not compete with programmers using the high level languages, as writing in assembler is time consuming. Since I have been using the higher level languages, I found myself working on work arounds to get what I really want done by the microprocessors, and am experiencing this hanging up more often. One of the main reasons for this, is that I no longer have any control of the assembler, as the compiler simply creates it's own assembler from the words that are writen on the screen.

[Brett Nortje]

Incorrect, the reason for the failure is due to poor software programming/techniques.

From my experience, these high level languages are to make a programmers life easy, however they introduce much much more "Noise/Clutter" into a software routine. The library routines are made to attempt to take into consideration, every conceivable solution to a library call. By doing this, the programs become so large, that they get lost, and hence the blue screen, or a static screen or where the device simply does not respond to a users input/request. The other reason, is that modern programmers have no clue how the hardware works, and simply program away to get something to market as soon as is possible, with out doing a thou rough check, and leave it to the user to find the bugs and report it to the programmer. When writing in assembler, you have to really know your nuts and bolts, and tend to test the programs for almost all types of eventualities. I even go so far as doing EMI surge noise testing, because this is what causes the micros to go astray. Remembering that a code word cause the micro to perform a task a, and by changing a single bit will cause the micro to perform task B, it simply shows that the micro no longer follows the flow of code that was written. This single bit or multiple bit changes happens with EMI pulses and surges on the line. A good well writen program will pick up that the program is going the incorrect path, and will allow the WDT to reset the processor and recover the data that it was working with, check the integrity of the data, and continue the program from where it went hay wire.

I will give you an example. I have a product, in which my last software update was done in 2000, it uses an 8 bit microprocessor, and uses 2K of program space in which I used assembler. Built into this program is a device called a "Watch Dog Timer", which basically means that routines must run with in a time frame, or else the processor will be reset, and the program starts again. This is to prevent the program from getting stuck/hanging somewhere The trick is to make the reset of the program totally transparent to the user, and the machine under control. In the high level languages this is practically impossible, because the high level language adds into your program a bunch of so called housekeeping routines which must first run when a processor is reset, making the seamless recovery very difficult, and require the programmer to make work arounds to attempt to get somewhere near where the program was when it was reset by the watch dog timer.

In this program I have a built in 32bit multiplier and divider, which does a 3rd order polynomial. If I attempt rewrite the program in a higher level language, such as 'C', I will need a minimum of 16K of program.
I am unfortunately moving away from assembler, simply because I can not compete with programmers using the high level languages, as writing in assembler is time consuming. Since I have been using the higher level languages, I found myself working on work arounds to get what I really want done by the microprocessors, and am experiencing this hanging up more often. One of the main reasons for this, is that I no longer have any control of the assembler, as the compiler simply creates it's own assembler from the words that are writen on the screen.

Oh, of course! yes, i understand now. i do not have a practical knowledge of how it works, but rather a layman and theoretical insight.

[Ervin]

Incorrect, the reason for the failure is due to poor software programming/techniques.

Sometimes yes, but not always. You can use the latest methods and languages, but results still can be far from your expectations.

[HR Solutions]

Is this like a private conversation between yourself....it doesn't make much sense!

Lol ..... exactly, but who are we to say anything .... I must be honest I can see why he "has left/asked to leave" other forums.

[Justloadit]

Sometimes yes, but not always. You can use the latest methods and languages, but results still can be far from your expectations.

An interesting point to observe, the high level language compiler is written with another high level language, and this may influence nesting and how the program compiles, and then executes the program.
Some experiences required to change a number of commands on one line to multiple lines to make the compiler compile better.

[irneb]

An interesting point to observe, the high level language compiler is written with another high level language, and this may influence nesting and how the program compiles, and then executes the program.

That's usually the case. A compiler for a very minimalistic language is made using assembly. Then this is used to make a compiler for a more capable language. Sometimes this process is repeated until the final language has a compiler which produces optimal "enough" code.

Even in some cases the same language itself is used to make its own compiler - referred to as Bootstrapping. Actually that's the usual case these days. Previously it would have been more prevalent to see a compiler made using some low level language (even entirely in assembly). But seeing as a compiler isn't needed to run extremely optimally itself, it makes more sense to use a high level language to write it - thus the programmer spends more time on the algorithms of translating source code to binary code and adding extra optimizations (i.e. more focused on the compiler's results) instead of worrying about how fast the compiler itself runs and how much ram it uses.

The thing to remember is that a compiler is nothing else than a "translator". It changes source code from one language into another. The usual case (for what is known as ahead of time compilers) is to translate some "high" level language (e.g. C) into machine code (i.e. binary codes which the CPU "understands"). You could see it as changing from one language into a language which gets run by the CPU, same as something like Java which gets compiled to an intermediate language (JVM byte-code) which then gets interpreted (run as it's loaded) through the JVM which itself is a machine-code compiled program.

Some ahead of time compilers tend to optimize the results better than others. And it's still possible to use a disassembler to convert the binary results from such compiler into ASM files which you can tweak to achieve even better results (if you know what you're doing). The problem with this of late is that most of the CPUs these days have an assembly language designed for compilers, not humans - so chances are you'd be extremely hard pressed to surpass the optimizations a decent compiler achieves by manually tweaking the assembly.

Even with those intermediate language compilers you can also still tweak the intermediate language itself. E.g. you can use something like ILDasm to change the DLL file into IL source. Not to mention most of these types of environments have a JIT compiler built into their runtimes - which performs optimizations as and when it runs the intermediate code. Sometimes such could even outperform an ahead of time compiler, like optimizing due to runtime data content (which an ahead of time compiler would not have known about).

Concerning the situation of some "languages" causing slow downs - that's true in some cases, not all. Usually the biggest culprit of this is garbage collection - i.e. a language / virtual machine environment designed to "clean up" the memory without needing the programmer to concern himself with those issues. The usual problem is that the entire program gets halted while the garbage collector checks if previously allocated RAM is still used - this is a big problem in Java. This is usually the major reason VMs and JITs do not surpass ahead of time in speed and definitely not in memory usage - a rule of thumb is that to get the same speed from Java's JIT as you'd get from a compiled C++ program you need 3 to 10 times as much RAM.

[irneb]

The other reason, is that modern programmers have no clue how the hardware works, and simply program away to get something to market as soon as is possible, with out doing a thou rough check, and leave it to the user to find the bugs and report it to the programmer.

Too true!

The problem with some programmer who've only ever known some high level language (especially a normally interpreted / intermediate compiled language such as Java) is that they don't "know" what's going on behind the scenes. Thus they tend to not even realize what's going on behind the scenes - thus getting situations where they select the wrong data structures, or use the wrong parameter passing strategies, or use heap allocation in preference to stack, etc. The major issue with these high-level languages is that they tend to hide the actual memory allocation, in most cases to such an extent that these programmers have never even heard of stuff like pointers and cpu cache alignment.

I always advise a prospective programmer to at least also learn a low level language. At least C, but preferably ASM. Even better would be to learn some HDL to understand the internals of the CPU itself (i.e. how to design the logic gates to interpret the binary codes). This gives a very good understanding of why some decisions are better than others for certain circumstances. E.g. a multi-dimensional array may be iterated faster if you can get contiguous areas into the cpu cache, or using an array when you need to insert / remove from the head is not the best idea (instead use something like a linked list or better a circular array). Which to learn first I'm not too sure of - personally I like with starting with a high level, then once getting to a decent capability start something like C/ASM and once you've got the gist, go back to the high-level and try to see what you can do to make your previous programs "better".