Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Re:Why do people still care about C++ for kernel d (Score 1) 365

Smart pointers in C++ are rarely larger in size than normal pointers.

std::unique_ptr has the same sizeof of void *. std::shared_ptr has the same sizeof as void *, but adds another allocation. Then again, boost::intrusive_ptr has the same sizeof as void *, does reference counting, does not require virtual functions in the destination class and carries no extra allocations (but does require that the class being indexed be aware it has references).

Shachar

Comment Re:Why do people still care about C++ for kernel d (Score 1) 365

Yeah, Linus mentioned those too. Where does C++ do hidden heap allocations?

The only example I can think of is when throwing an exception (and see below about that), and even then, the compiler rarely actually performs a heap allocation. Small exception classes are stored in a pre-allocated static buffer.

And if you are talking about library use, then you need to realize two things:
1. STL is the most allocation aware library I have ever seen. With a few C++11 related exceptions, it will always allow you to pick an allocator, and will always avoid allocation where one can be avoided.
2. If you think even that level of care is not enough, then you are free to not use STL. Assuming you are correct, your options are "Don't use STL, implement your own implementation in C++" or "Don't use STL, implement your own in C", and I fail to see how option 2 is preferrable to option 1.

As for the other two, RTTI cost you a few extra bytes per defined class (not instance). You are free to tell your compiler not to generate those if you don't use it (for user space, I rarely bother).

Exceptions are a different story. They get a very bad rap, and it's only partially justified. There are two reasons to not like exceptions for kernel code. The first is that exception use is a fundemental design decision. It is not something that can be slapped on to existing code. To do it properly, you must also have RAII and a good structuring of your code. Since those two are a good idea regardless, most good C++ programmers don't mind, but it's hard to migrate existing code to use it properly.

The other reason exceptions are not liked is because of a design decision made by the C++ committee that exceptions have no runtime cost when an exception is not thrown. This leads to the compiler generating the same code twice, and to a very complicated stack unwind code. I don't think either of these will prevent exceptions from working in the kernel (given the proper adaptations), but I do understand how these cause people to be weary of them.

I do agree with Linus about one thing. C++ is a language that is too complex. This leads to good C++ programmers being a minority among C++ programmers.

Shachar

Comment Re:C=128 (Score 1) 167

What only Amiga users know is that the only way the power led can be controlled is by enabling/disabling the low-pass filter on the audio output since the status of the enable signal is indicated by dimming the led. It's not possible to turn it off completely to simulate the computer being dead.

The original Amiga 500, including the early Kickstart 1.3 ones, would actually completely turn off the LED. If you don't believe me, you are welcome to visit me. I still have my original machine in (more or less) working order.

You are correct that later models would not turn it off completely, but rather only dim it. I only remembered that fact after I hit Send, and thought no one will be anal enough to demand a clarification.

It's also possible to read a single sector, but that would require starting the DMA on a timer so it's more cumbersome than reading the entire track and it's not guaranteed to be faster since it's a spinning media.

In other words, the hardware does not support it.

As for MFM/RLL encoding the floppy controller does neither, it reads the raw bits. The order of the bits is interleaved on Amiga formatted disks to allow for blitter accelerated MFM-(de)coding.

That is one point I am not as sure about. It goes against what I remember, but I might be wrong on that point. However:

Don't trust anecdotes, the developer guides are available online.

Do provide links. Please. I failed to find them, and my black 2.04 books are buried in some box from my latest moving day (if I had not thrown them out).

Shachar

Comment Re:C=128 (Score 1) 167

If I remember correctly changing display modes mid scan was often done so that workbench could do things like display HAM images in windows.

You misremember. The Copper code to change display modes took several scan-lines to run. Having a window with different display mode was impossible. You could, and did, have a UI construct called a "screen", which had its own display mode. You could drag a screen down and see another screen behind it.

All three were used though and it was used for many things such as sprites and the above mentioned screen mode changes.

AFAIK, none of those utilized SKIP. They were all based on WAIT and MOVE. If you know differently, please provide further details.

Maybe I missunderstood the OP?

I don't think so. I am, however, fairly sure you mis-remember.

Shachar

Comment Re:C=128 (Score 1) 167

You got a partial answer. If "SKIP" was ever used, I'm interested to know by whom. I only know of a single example, which was EXTREMELY special case.

The commands:
MOVE: move immediate value into copper register. These included such actions as where in memory the video memory was (i.e. - where to fetch the picture from), what is the palette, video resolution, where on screen the video fetch starts and where it ends and many others.
WAIT: wait for the screen update to reach a certain point. There was a mask argument which allowed you to have don't cares on some of the bits.

These two was how most of the programs worked. From simply displaying a static image (the memory fetch registers had to be reset each frame), through "copper waves" (things like telling the hardware to start displaying the image in a different timing each line, so that a straight in memory was a wave on screen), to what matfud erroneously called "display HAM in a window" (it took several scan lines for the copper to completely replace the display mode, so you couldn't display two modes side by side, but you could display them one above the other). It also allowed "virtual sprites" by reusing the same 8 hardware display sprites for different things in the same frame, so long as they were not in the same line.

The third command, skip, had the same arguments as WAIT. Instead of waiting, however, it skipped the next command if the condition was not met. Add to that copper registers that restarted the copper program if written to, and the fact you could load two start addresses and switch between them, and you get the ability to perform a loop.

Back in 1994 there was a Mac "emulator" called A-Max. It was not really an emulator. It loaded Mac ROMs into the ram, patch some hardware related entry points so that it would work on the Amiga, load a copper instruction that caused the Amiga display to act like a Mac black & white display, and simply executed the ROMs. As a result, a 7.2Mhz Amiga 500 ran programs written for the 8Mhz Mac at 120% speed.

One (rather minor) problem they had was that while the display content was showing correct colors, the Amiga was hard-coded to use color 0 for the overscan. As a result, the overscan, black on the Mac, was white on A-Max. Around 1993 I figured a way to resolve this, using the SKIP command and the loop method mentioned above. I assumed that if I figured it, it was obvious, and didn't do anything with it. Around a year or two later, A-Max released a version which had text similar to the following:
Thank you (don't remember the name) for providing us with a method to give a black overscan without writing a huge copper program. As thanks, we've given him a free version of A-Max.

Which caused me to kick myself no ends, and never assume my ideas aren't innovative.

As far as I know, there was no other use for the skip command (which might explain why the A-Max guys never thought about it themselves).

Shachar

Comment Re:C=128 (Score 5, Informative) 167

And then Commodore went on to (half inherit, half design) the Amiga. Maybe "cobbled together" is too harsh for it, but still. Floppy controller that can decide, per track, whether to work in MFM or RLL (but not read a single sector, mind you), more DMA channels than the CPU can handle, and a display processor with a built-in three commands machine language (one of which was only ever used by one application ever) to change display resolution mid-monitor.

I loved it, but the Amiga gave the impression that it was designed by engineers that couldn't make up their mind on what choice to make, so they created hardware that would offload all decisions to software.

One last anecdote. Many have heard of the famous "Guru meditation". What only Amiga users know is that you knew one was coming because the power led would blink three times. Yes, the power led was software controlled, making the Amiga the first ever computer that could play dead.

Shachar

Comment Re:The film sucked; the miniseries before it was g (Score 2) 39

Yes, but that's not the whole story (sorry about the pun).

Douglas Adams once said that every new medium he adapts to is a rewrite for him. He, quite deliberately, did not repeat the same story in a different medium, but rather wrote a new story loosely based on the same plot and characters.

Some of the differences between the movie and other adaptations were clearly not a dictation of the medium, but rather an artistic decision. Two random examples: in other portrayals Zaphod's heads were side by side and the heart of gold, at least in the books, was shaped like a sneaker shoe. The only reasons to change those are artistic, not medium related.

Yes, when you adapt a story to a new medium it was never told in before, changes are inevitable. To me, the best case scenario is that someone who understands and loves the original story embraces this fact, and tries to recreate a new story that captures as much as possible that was good in the original.

In fact, those movies which do try to capture the original books as accurately as possible are those I enjoy less. When I see them, I've either already read the book, or it is a few clicks away. By all means, give me a different story in the movie.

Shachar

Comment Re:huh? (Score 2) 269

According to that logic, if I own an apartment, and I rent it out to you, I can video and audio record its interior.

It doesn't work that way, and that's a good thing. When you are driving a car, you have a reasonable expectation that you are not being watched and recorded all the time.

The country I live in (Israel) is strictly a "one party" country. Recording the inside of a car is, however, a case where none of the parties to the conversation are aware of the recording. It wouldn't pass here either.

Shachar

Comment Re:Bullshit (Score 1) 221

A while back my wife had to go to Jeruslaem on the same day George W. Bush was visiting there. I let her know she was going to spend the day sitting in stand-still traffic.

Turns out, I was wrong. So many people assumed the same thing that nobody travelled to/from the city that day. The roads, when not blocked, were empty.

Shachar

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...