The Classic [modified]
-
CDP1802 wrote:
But I often wonder how people fare, who started out with something like .Net and Java.
Taught myself assembler on an old 386 in a very boring support job. Lowest I get to these days is MSIL ... sadly most .Net developers aren't even aware of that. In a previous gig I had code that added dynamic methods to reset resources. Not only did the other developers not know about dynamic methods, they didn't even know what IL was .. sad.
I'm largely language agnostic
After a while they all bug me :doh:
It's not the first time such things have happened. I know a blacksmith. A real blacksmith, who really still works at his anvil. His profession almost does not exist anymore. We have all kinds of sophisticated means of producing high quality steel on an industrial scale, but the knowledge how to manually shape steel and give it the desired properties is almost lost. I guess it will be reinvented if and when the need should arise.
-
The good old CDP1802 must be one of the oldest CPUs which still in production. I used it in my first self built computer (which still exists and works). The 1802's instruction set foreshadowed the later RISC processors and therefore is no horror at all. For a beginner a CDP180X (all CPUs of that line had almost identical instruction sets) there can be no friendlier processor to program. A very compact instruction set, few addressing modes, 16 registers for general purpose use (just take two of them as you like as PC and SP), one single bit (DF) which elegantly serves as status flag for all processor operations... And, as I hear, the little 'horror' still does it's job after more than 30 years in space in the Voyager probes. And yes, it had a real hardware horror: A multiplexed address bus.
CDP1802 wrote:
I used it in my first self built computer
My aims were somewhat grander - I managed to talk our rep into a sample of a 68000 (an 8MHz version if I recall) when they cost in the hundreds of pounds. I still have it somewhere. The outcome was somewhat poorer than yours, although I did use it to flash a LED I never got round to building the computer, bought an 8086 box instead.
Peter "Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
-
CDP1802 wrote:
I used it in my first self built computer
My aims were somewhat grander - I managed to talk our rep into a sample of a 68000 (an 8MHz version if I recall) when they cost in the hundreds of pounds. I still have it somewhere. The outcome was somewhat poorer than yours, although I did use it to flash a LED I never got round to building the computer, bought an 8086 box instead.
Peter "Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
Take a look here: http://www.cosmacelf.com/gallery.htm[^] The first one on the second page of the gallery resembles mine, but of course no two of those machines were absolutely alike. I was a kid back then and it was the only way to get my hands on a computer. My parents did not know what to think of this, sometimes they still wonder today :)
-
Certainly. A user interface which sits there most of the time, waiting for some event to happen, would not profit much from assembly code. Also, I would not want to lose all benefits from object oriented programming. But then comes something, that needs a little optimisation. Sometimes you can't just write beautiful high level code and tell the customer to buy a faster computer. But it seems, this is a lost art. Many 'modern' developers tell me that the compilers are good enough (I usually tell them that this means they are not), the next generation of processors will bring more than any optimization, and of course, that optimization costs too much development time.
CDP1802 wrote:
Sometimes you can't just write beautiful high level code and tell the customer to buy a faster computer.
Oh I don't know, Microsoft does it all the time! :((
-
I freely admit it: I have done this frequently in the past and I will do it again. And it holds countless horrors for those who are not used to it anymore:
void SomeClass::SomeMethod()
{
asm
{
// here the horrors begin
....
}
}Seriously, I once began on a small self-built machine and typed in machine codes with its hex keypad. Compared to that some C++ inline assembly code is already high level. But I often wonder how people fare, who started out with something like .Net and Java. Edit: How do I indent the code lines correctly with this editor? Tabs and spaces will not work.
modified on Monday, May 5, 2008 9:25 AM
asm keyword does nothing in Visual C++[^]. You need to use
__asmAlso, inline assembly is not supported with the x64 compiler. Back to MASM, I guess :) -
asm keyword does nothing in Visual C++[^]. You need to use
__asmAlso, inline assembly is not supported with the x64 compiler. Back to MASM, I guess :) -
I freely admit it: I have done this frequently in the past and I will do it again. And it holds countless horrors for those who are not used to it anymore:
void SomeClass::SomeMethod()
{
asm
{
// here the horrors begin
....
}
}Seriously, I once began on a small self-built machine and typed in machine codes with its hex keypad. Compared to that some C++ inline assembly code is already high level. But I often wonder how people fare, who started out with something like .Net and Java. Edit: How do I indent the code lines correctly with this editor? Tabs and spaces will not work.
modified on Monday, May 5, 2008 9:25 AM
While we're talking, couldn't a asm programmer use inline asm{} as the entire code and claim it to be C++ code? (or something like that)
Dim SomethingAboveMyHead As LightBulb Let Go = Grip.Release() -
While we're talking, couldn't a asm programmer use inline asm{} as the entire code and claim it to be C++ code? (or something like that)
Dim SomethingAboveMyHead As LightBulb Let Go = Grip.Release()You mean declaring classes as usual, but then using inline assembly only in the implementation of the methods? Yes, that's certainly possible, but does not make much sense. 90% or even more of the code would not benefit very much from assembly code, so why make it harder to read without a gain? Take the user interface. It usually is idle while waiting for some event to occur. Then it briefly handles the events and sits there and waits for the next event again. Handling events comes in two flavors: Quick enough (so why use assembly?) or much too long. Often so much too long, that no optimization can bring it into the quick enough category. Opening and synchronizing a worker thread for this is certainly better done in C++. If the execution time of this thread then still is an issue, assembly optimization at a few well-selected spots may do the trick. The rsult is a much more maintainable and readable code. Also, there is still the option to use an assembler to write critical functions and to link the object files with your C++ project. Personally, I don't like mixing up different languages in one source file. My best argument against it is a typical PHP script with HTML, PHP and occasionaly embedded JavaScript merrily mixed into one ugly spaghetti code. I would even prefer to use Visual Basic and gladly suffer all the consequences than ever to do serious work with PHP.
-
Sorry - but I have to say this isn't a horror. Sometimes it's just plain necessary.
Deja View - the feeling that you've seen this post before.
True. I use the CPUID instruction as part of a diagnostic reporting operation. The information reported isn't available from a Windows API (AFAIK).
Software Zen:
delete this;
Fold With Us![^] -
It's not the first time such things have happened. I know a blacksmith. A real blacksmith, who really still works at his anvil. His profession almost does not exist anymore. We have all kinds of sophisticated means of producing high quality steel on an industrial scale, but the knowledge how to manually shape steel and give it the desired properties is almost lost. I guess it will be reinvented if and when the need should arise.
Interesting. Up until about ten years ago, one of the last farrier[^] schools in the world was down the street from me. I believe they moved to the Lexington Kentucky area (lots of horse farms).
Software Zen:
delete this;
Fold With Us![^] -
Take a look here: http://www.cosmacelf.com/gallery.htm[^] The first one on the second page of the gallery resembles mine, but of course no two of those machines were absolutely alike. I was a kid back then and it was the only way to get my hands on a computer. My parents did not know what to think of this, sometimes they still wonder today :)
Boy, does that bring back memories. My stepdad built one of those with a hex keypad and two digit display. We even found a Tiny Basic interpreter for it. I fat-fingered it in (all 1.5K) about three times before I got it all right. He also renovated a KSR-33 teletype as an I/O device. The most ambitious thing John ever did with it was to write a mortgage amortization table program for it. This was a pretty neat trick, considering that Tiny Basic only gave you 26 16-bit integer variables (A through Z, of course). His program worked. I remember it chugged away, printing the table on that freight train of a teletype all night.
Software Zen:
delete this;
Fold With Us![^] -
I also see it that way. At college a professor tried to tell me that I can't possibly write better code than a compiler. I proved him wrong, but it's not really hard do better than a compiler in most cases. But I had the impression that many people feel uneasy about going down to assembly level. They are used to all kinds of high level comfort and it seems to be a horror for them to give it up.
//At college a professor tried to tell me that I can't possibly write better code than a compiler. I proved him wrong, but it's not really hard do better than a compiler in most cases.// I have found that, in general, the smaller a routine, the more likely it can receive a big speedup from hand assembly (at least if it doesn't match a particular 'pattern' the compiler can recognize and optimize). Some years back I wrote a game for an XT which had about 20 lines of assembly code in a 1400-line game. The assembly code ran about ten times as fast as what the compiler could generate, and yet still represented about 80% of the main loop's worst-case execution time. Nowadays a lot of my hobby programming is in assembly language, though. On a game machine with 128 bytes of RAM (code runs from ROM) when there are 76 clock cycles per scan line to handle display drawing, assembly code is pretty much a must. A BASIC compiler exists using some pre-defined display kernels, and people have done some cool things with it, but for real power programming hand-written assembly is the only way to go.