 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
Unfortunately, it seems to be in the nature of things that useless
discussion drag
on and recur while the useful ones appear only once for a moment. But
this one hasn't
been entirely useless to me. :)
The main problem though, apart
> from this being the wrong group is that you restarted a useless
> discussion for the 42nd time.
>
>> :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> A lot of people just find it makes more sense to
> have one file that neatly shows the interfaces and another to actually
> contain the implementation code.
In fact, one of my biggest complaints with C# is the lack of class
prototypes. I miss having a public interface which fits entirely on one
(maybe two) screen(s). Somehow, it seems to make things easier for me.
--
Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 22 Jul 2009 20:00:21 -0500, David H. Burns wrote:
> Jim Henderson wrote:
>> On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:
>>
>>> What can be off-topic to off-topic?
>>
>> Why, anything that's on-topic, of course. ;-)
>>
>> Jim
>
> Obviously, but I hadn't thought of it that way.
That's perfectly OK - I was just kidding around, had hoped the smiley
would tip that off. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The way this works on the Amiga is that you can't just *call* an OS
> function. First you have to look up its base address in a table.
> Basically, memory address 0x00000004 contains a pointer to a table. Every
> OS function has a unique ID which is an offset into this table, which
> enables you to lookup the function's base pointer. And then you can jump
> to it. All of which takes about two-dozen assembly instructions...
On the Acorn there was an instruction called SWI (software interrupt) for
calling OS and other module functions. In the assembler it took a number or
a string as a parameter (the assembler converted the string to the correct
number), which defined the specific function you wanted to call. I assume
when the CPU got to the SWI instruction it jumped to a few lines of OS code
which figured out where to actually jump to execute the instruction.
When you loaded "modules" to the OS (they were like services under windows)
each module could register some functions with the OS. Then you could call
them with the SWI instruction. It was pretty easy to use.
You could easily hack the system though by redirecting the interrupt handler
to your code, calling the real OS handler, then passing control back to the
calling program. Of course in your code you could then check for certain
functions (like reading the contents of a folder) and modify the results :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <Ben### [at] gmail com_no_underscores> wrote:
> > the buck does *not* stop here.
>
> Shouldn't that be "the Buck"? ;)
??
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> > the buck does *not* stop here.
>>
>> Shouldn't that be "the Buck"? ;)
>
> ??
I know in German you use a capital letter for every noun, but in English
it's usually just for names.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I see. So you still have to manually define what needs to be linked
>> somehow?
>
> Lets just say I'm working with source files right now where the line
> used to compile the file takes up more than one screen of text in the
> editor.
Yes. For some reason, this seems to be mandatory in all Linux
development. I'm not sure why...
>> - When main.c is compiled, it produces main.o, which contains several
>> references to a foo() that should exist somewhere, but we don't know
>> where yet.
>
> No. Only if main() actually calls foo().
One assumes that if you don't need foo(), you wouldn't bother including
the header file. But sure, if the header declares a few dozen functions;
you might not call every single one of them.
>> - The linker takes main.o and foo.o, and replaces every jump to foo()
>> with a jump to an actual machine address. The resulting program is
>> actually runnable.
>
> Sort of. That's called "linking." Then there's "loading", which is when
> you put it into memory and *again* adjust a bunch of addresses.
Right. So what you're saying is that there's actually a second linking
stage each time final executable is run?
>> What I can't figure out is what happens if foo() is actually a
>> function somewhere in the OS kernel.
>
> It isn't. The read() function in C, for example, is in the C runtime
> library (glibc or uclibc on Linux). The linker always searches that
> library as part of the linking process (unless you're doing something
> funky like compiling the kernel). The read() function in that library is
> written in assembler (because C is really not very useful for this sort
> of work) and that assembler code copies items off the stack into machine
> registers and then invokes an assembler instruction that causes the CPU
> to set certain flags in the CPU registers that control permissions,
> change memory maps, and eventually winds up branching to a particular
> address in memory which the kernel has previously set to be a branch
> instruction to the code to handle read(). So read() is normal, except
> it's in a library the compiler always searches and contains assembly
> language.
In summary... you can't call the OS from C. You can only write C wrapper
functions around the assembly code that calls the OS. (And the wrapper
then of course looks like a normal C function...)
>> Presumably in each version of the kernel, the base address of this
>> function is going to be different... so how the hell does the linker
>> know what it is?
>
> It doesn't. It executes a machine-code instruction that's essentially a
> software interrupt. (That's why you see things like DOS functions being
> described as "Int 21h" functions.)
>
> It's an instruction that invokes an indirect branch.
I see. So that's the mechanism on the IA32 platform, is it? (I thought
only the BIOS uses this method...)
>> The way this works on the Amiga is that you can't just *call* an OS
>> function.
>
> There's no memory protection or kernel mode on AmigaOS. It can't be
> multiuser.
Interestingly enough, the Motorola 68000 does in fact have two modes of
operation: "user mode" and "supervisor mode". I have no idea what the
distinction is.
Additionally, the factory-standard Amigas had the "EC" version of the
Motorola 68000 CPUs which lack an MMU. You can, however, replace this
with a version of the CPU that possesses an MMU. Indeed, several
companies offered the add-on boards, together with the necessary
software to extend AmigaOS to support virtual memory. This suggests that
the MMU-enabled variant of the CPU could support memory protection if
you wanted.
And finally, it's perfectly possible to make a multiuser OS without
memory protection. It just won't have any memory protection. (Meaning
one rogue program can crash the whole system.) Arguably not very useful,
but completely doable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
>>> Yes, being active in the development of POV-Ray 3.7 I *may* happen to personally
>>> get my hands dirty on the code of POV-Ray 4's SDL engine.
>> So it is so after all
>> :(
>
> So it is *what* after all? Me single-handedly going to take over the world or
> what??
That's what it sounds like, the Pov-Ray world anyway. You've greatly
increased my paranoia.
Any day now I expect the carpenter's union to redesign and rebuild my
house not for
convenience or comfort but to teach me the current accepted practice in
carpentry.
>
> Mwahahaha - Yeeees - I've always wanted to do that...
>
> Ah, BTW & FYI: Me being a contributing developer to POV-Ray doesn't mean that
> I'm member of the official dev team. I do contribute code now and then, but as
> for making decisions about which direction to go, the buck does *not* stop
> here.
Despite my concerns, I do appreciate all the work that the official and
unofficial
of Pov-Ray have done over the year --excellent work for my part.
David :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> For one, OOP more closely models how many people think of problems,
> while functional programming more closely models how mathematicians
> think of problems.
??!! Though the second clause of this sentence seems true to me, nothing
that I have read or heard in a long time seems so obviously false! It
makes
me wonder if I'm communicating with an entity of a different a species
or even
a different genus! (Is there an exclamation or ??!! icon?)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> This is where I mutter something about functional programming being
>> the future, and everybody agrees with me...
>
> There is still some debate about that, of course :)
That was actually sarcasm. ;-)
> For one, OOP more closely models how many people think of problems,
> while functional programming more closely models how mathematicians
> think of problems.
Depends who you think you're aiming your programming language at.
> It is not yet clear which one is better for managing
> large, complex programs in general.
People who use Haskell casually build interpretters, compilers, logic
simulation systems, and other things usually thought of as "hard" in
normal programming languages. Whether this is to do with Haskell or the
sort of people who use Haskell remains to be seen of course... ;-)
> (especially since there are many
> things a computer does that are still more closely aligned with
> imperative programming. These things are easier to wrap in OOP, which
> has concepts for both data and actions).
One might ask when computers will start to be designed to operate in a
more functional way...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
