Re: [9fans] Google search of the day - Plan9

This is a discussion on Re: [9fans] Google search of the day - Plan9 ; Anant Narayanan wrote: > Just as an observation (may not be related to the thread), all the > executable file formats that Linux currently supports, have page- > aligned sections in the file! ... > That means, all the loader ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 70 of 70

Thread: Re: [9fans] Google search of the day

  1. Re: [9fans] Non-stack-based calling conventions

    Anant Narayanan wrote:
    > Just as an observation (may not be related to the thread), all the
    > executable file formats that Linux currently supports, have page-
    > aligned sections in the file! ...
    > That means, all the loader really does is mmap the sections into the
    > right memory locations. What next, maybe also put in the BSS in the
    > file so you wouldn't have to allocate that either


    Ssh, somebody may hear you and decide to do it.
    Conceptually it's not a bad idea, in environments where you can
    spare the wasted space. As I recall, using the VM system to map
    files in Unix goes back to 4BSD; we used to page-align buffer
    addresses in order to get the kernel to perform faster data
    transfers.

    > Hence, writing the loader for Plan 9's a.out proved to be a challenge.
    > I ended up writing a user-space program that padded out the required
    > gap between TEXT and DATA before asking the kernel to execute it.
    > Suboptimal, but it works.
    > If anyone has any ideas as to how I can improve the situation, i'll be
    > grateful.


    I don't understand what good it does to map Plan 9 object code
    into Linux files. Is there a Linux filetype for Plan 9 that
    invokes a system-call interpreter, or what?

  2. Re: [9fans] Non-stack-based calling conventions

    "Federico G. Benavento" wrote:
    > ... but who wants to be a wannabe anyways?


    Maybe a has-been wannabe has wanted to be?

  3. Re: [9fans] Non-stack-based calling conventions

    maht wrote:
    > For the C version there's all sorts of pushing and popping return
    > addresses and arguments on to the stack
    > float
    > sqr(x float)
    > {
    > return x * x;
    > }
    > float
    > hyp(x float, y float)
    > {
    > return sqrt(sqr(x) + sqr(y));
    > }


    [Assuming that the code is corrected and the types made compatible
    with the argument to sqrt.]
    The extra overhead occurs only because of the support for full
    recursion, with private instance data. Many C compilers dating
    back to around 1980 will in-line the calls to sqr, so the effect is:
    hyp: mul r2,r2,r2
    mul r3,r3,r3
    add r2,r3,r2
    jmp sqrt
    It's hard to imagine anything more efficient (except when hyp
    itself can be in-lined.) Details of course depend on the machine
    architecture and linkage convention; the above is modeled loosely
    after the M*CORE, which is very nice in this respect.

  4. Re: [9fans] Non-stack-based calling conventions

    Lluís Batlle wrote:
    > Maybe someone in this list can provide a good example of coroutines use?


    Check out http://en.wikipedia.org/wiki/Coroutine for examples and discussion.

  5. Re: [9fans] Non-stack-based calling conventions

    On Fri, Feb 22, 2008 at 7:01 AM, Douglas A. Gwyn wrote:
    > Eris Discordia wrote:
    > > do Plan 9 compilers output COFF object files?

    >
    > No, it has its own format. Actually Plan 9 is interesting
    > in that some of the work traditionally done by the compiler
    > was made the responsibility of the linker.
    >


    like douglas said, the linkers will do the job and output COFF for you.

    iru

  6. Re: [9fans] Non-stack-based calling conventions

    On 22-Feb-08, at 3:32 PM, Douglas A. Gwyn wrote:
    > I don't understand what good it does to map Plan 9 object code
    > into Linux files. Is there a Linux filetype for Plan 9 that
    > invokes a system-call interpreter, or what?


    No, I just write a handler for interrupt 0x64 that calls either an
    existing linux syscall (it works for some of them) or a custom in-
    kernel routine (for the more 'exotic' plan 9 syscalls).

    Yes, the project is currently aimed at x86 only.

    --
    Anant

  7. Re: [9fans] Non-stack-based calling conventions

    I'm quoting out of context as they were discussing the design of the
    Inferno VM but Phil Winterbottom & Rob Pike mention in
    http://www.vitanuova.com/inferno/papers/hotchips.html :

    "One might argue that a stack-based processor design would mitigate the
    difficulties, but our experience with the implementation of a stack
    machine in the AT&T Crisp microprocessor [5] leads us to believe that
    stack architectures are inherently slower than register-based machines.
    Their design lengthens the critical path by replacing simple registers
    with a complex stack cache mechanism."

    5. Ditzel, D. R. and McLellan, R., ``Register Allocation for Free: The C
    Machine Stack Cache'', Proc. of Symp. on Architectural Support for
    Programming Languages and Operating Systems, March, 1982, pp. 48-56.

    I found the paper at http://portal.acm.org/citation.cfm?id=960120.801825
    but you have to have a paid account so I have no idea of their
    conclusions beyond Rob & Phil's comment
    It is a widely cited paper though, so it must be a good read. (and I did
    find loads of other great stuff while trying to find it)

    The Crisp sounds like something interesting, anyone know much about it?

    I found this again at acm
    Design tradeoffs to support the C programming language in the CRISP
    microprocessor
    http://portal.acm.org/citation.cfm?i...=portal&dl=ACM

    and this at ieee
    CRISP: a pipelined 32-bit microprocessor with 13-kbit of cache memory
    http://ieeexplore.ieee.org/Xplore/lo...6/01052813.pdf

    seems that information doesn't want to be free today

    > I've got some time to delve into Fascicle One again and indeed, MMIX
    > doesn't have any stack at all. When you need stack, you implement it
    > yourself. Anyone knows of other CPU's using this method for stack
    > (i.e. no in-built support for stack in memory)? There is stack based
    > on registers, though.
    >



  8. Re: [9fans] Non-stack-based calling conventions

    > I'm quoting out of context as they were discussing the design of the
    > Inferno VM but Phil Winterbottom & Rob Pike mention in
    > http://www.vitanuova.com/inferno/papers/hotchips.html :
    >
    > "One might argue that a stack-based processor design would mitigate the
    > difficulties, but our experience with the implementation of a stack
    > machine in the AT&T Crisp microprocessor [5] leads us to believe that
    > stack architectures are inherently slower than register-based machines.
    > Their design lengthens the critical path by replacing simple registers
    > with a complex stack cache mechanism."


    I haven't been following the Non-stack-based calling thread
    closely, but this comment is not about using the stack
    in procedure calls. They are talking about stack *machines*.

    push value
    push value
    add
    pop value

    The Pacal P-machine, the Lillith microcode and the Java Byte machine
    all come to mind. Note about calling. Intersting in any case.

    Ken Thompson seemed to be absent at most Usenix conferences, but at
    one I saw him line up at the mike after the talk on the BSD
    packet filter. He asked why they had used a stack machine. The
    poor fellow, who recognized who was asking the question looked
    like a deer suddenly lit by the headlights of a Peterbuilt.

    `It's faster?'

    `No, it's not!'

    End of questions.


  9. Re: [9fans] Non-stack-based calling conventions

    > 5. Ditzel, D. R. and McLellan, R., ``Register Allocation for Free: The C
    > Machine Stack Cache'', Proc. of Symp. on Architectural Support for
    > Programming Languages and Operating Systems, March, 1982, pp. 48-56.


    Some where in my junk I still have the description of the C70
    machine from BBN. No assembler. Calls to odd addresses called
    microcode.

    Just an aside.


  10. Re: [9fans] Non-stack-based calling conventions

    Dis on a Chip is not stack based. There are no stacks at all.
    A very real advantage is that there are hence no restartable
    faults. If my memory serves me right this was the reason that
    the C compiler for the Cray XMP had segmented stacks.
    (A call would check if there was enough left in the current
    segment and if not malloc and link another segment - yes it
    was fast enough to get away with this.)

    brucee

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4