Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

June Daemon News out and about

Nik posted more than 14 years ago | from the NP:-Crimestoppers-a-gogo dept.

Links 7

BSDJoe writes "The June daemonnews newsletter has been posted" Included in this issue are an introduction to the ports system, a length tutorial devoted to writing writing a CAM SCSI controller driver, and a great editorial about how to attract users without dumbing down.

Sorry! There are no comments related to the filter you selected.

NP:-foo (2)

howardjp (5458) | more than 14 years ago | (#1029210)

Okay Nik, what is up with the NP always in the department name?

Assembly and Ports (2)

questionlp (58365) | more than 14 years ago | (#1029211)

This month's issue of Daemon News has a very nice summary and overview of the Ports system and how to use it and how it's done. I haven't worked with Debian nor the apt-get utility, but the BSD ports system is definitely one of BSD's high points.

The only gripe I have with the ports system is that I don't always update the ports directory on my workstation(s) and sometimes I don't get the latest builds or revisions of an app I was hoping for. I don't know if one is in the works or not is a simple script or a pre-compiled utility that will check the revisions and dates of the ports stuff of the station and automatically pull down any new versions. I know this might be helpful if you want to keep an older version, but the utility could have the option to keep older versions and rename the new ones.

Anywho... something I found quite nice in this month's issue was the article on Assembly. I might not be up to par on my C/C++, but learning a bit of Assembly would definitely be worth while for me.

Re:Assembly and Ports (2)

gsutter (41875) | more than 14 years ago | (#1029212)

There is such a utility: CVSup. See the CVSup section [] of the FreeBSD Handbook [] for details.

You can also fetch and run CVSup very quickly and easily (as root) by issuing pkg_add -r cvsupit, which will go get the CVSupit package (a CVSup wrapped for easy installation and use), install it, and prompt you for what to do next.

Although these instructions are specific to FreeBSD, CVSup is an excellent tool for dealing with any source tree, including the other BSDs.


Assembly quirks? (2)

howardjp (5458) | more than 14 years ago | (#1029213)

Because Linux forces the user to pass system call arguments in the processor registers (and is it like this on all architectures?), does that mean it is limited in the number of arguments that can be passed?

Re:Assembly quirks? (2)

howardjp (5458) | more than 14 years ago | (#1029214)

And, while I am at it, are arguments to library calls passed the same way under Linux?

Re:Assembly quirks? (1)

Odradek (144336) | more than 14 years ago | (#1029215)

Nope. They go on the stack. (If they didn't, e.g. varargs functions like printf, sprintf, scanf, et al would not work.)

Re:Assembly quirks? (1)

Odradek (144336) | more than 14 years ago | (#1029216)

Even memory verification aside, accessing something which is located in memory is slower than accesing a register. For instance:

mov eax, ebx

Is always faster than the single instruction:

mov eax, [ebx]

This is simply because registers are located in the processor and can be accessed in a single clock cycle, whereas even very fast cache RAM still takes a bit more than this, not to mention cache misses, et cetera.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?