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

This is a discussion on Re: [9fans] Google search of the day - Plan9 ; I think the stack direction is just for the pseudocode, the stack in my implementation grew down, it depends on what assembler primitives are available I guess >> >> >> moddiv: >> colon >> divmod >> swop >> semi > ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 70

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

  1. Re: [9fans] Google search of the day

    I think the stack direction is just for the pseudocode, the stack in my
    implementation grew down, it depends on what assembler primitives are
    available I guess
    >>
    >>
    >> moddiv:
    >> colon
    >> divmod
    >> swop
    >> semi

    >
    > I am genuinely lost, do not understand a word of it.



    colon tells the inner loop that this is a set of other Words (addresses)
    not machine instructions
    so the loop will execute
    divmod (which does division with modulous and leave the divsor, mod on
    the stack)
    swop then reverses the order of the top two stack items
    semi then jumps to semi to pop the next I before jumping to it

    It gives you an interactive compiler without linking as you can add new
    Words at runtime

    :square dup *

    would put
    square :
    colon
    dup
    multiply
    semi

    somewhere in memory (called the dictionary)

    My version uses two stacks, one for args and one for addresses

    for more analysis I suggest some online reading, I'm not deep enough
    into either paradigm to offer suitable insights


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

    >
    > The calling conventions I have seen are the ccall, stdcall (Windows'
    > slightly modified version of the ccall), and pascal. All of them
    > push parameters on the stack.


    Take a look at the R-call and S-call conventions used on the IBM
    System 360 architecture. These machines didn't even have a stack.

    --lyndon

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

    - DOS interrupt function calls use the registers, not the stack.
    - SPARC and MIPS registers are provided to pass parameters.

    On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:

    >>
    >> The calling conventions I have seen are the ccall, stdcall
    >> (Windows' slightly modified version of the ccall), and pascal. All
    >> of them push parameters on the stack.

    >
    > Take a look at the R-call and S-call conventions used on the IBM
    > System 360 architecture. These machines didn't even have a stack.
    >
    > --lyndon



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

    I don't have latest version of fascicle one (MMIX processor
    architecture and MMIXAL assembler language, from new version of The
    Art of Computer Programming) at hand, so I can't confirm it, but I
    remember that MMIX had a special register which implemented a
    "border", shifting register numbers to use them for procedure data
    separation.

    And as in all RISC architectures, storing as many parameters in the
    call stack is the way to go. Especially when you have 256 64-bit
    general purpose registers :-) (Now if only someone implemented a sane
    architecture using MMIX as main processor...)


    On 2/16/08, Pietro Gagliardi wrote:
    > - DOS interrupt function calls use the registers, not the stack.
    > - SPARC and MIPS registers are provided to pass parameters.
    >
    > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:
    >
    > >>
    > >> The calling conventions I have seen are the ccall, stdcall
    > >> (Windows' slightly modified version of the ccall), and pascal. All
    > >> of them push parameters on the stack.

    > >
    > > Take a look at the R-call and S-call conventions used on the IBM
    > > System 360 architecture. These machines didn't even have a stack.
    > >
    > > --lyndon

    >
    >



    --
    Paul Lasek

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

    Early Control Data machines, like many machines
    of the era, used the return address to fine the parameters.
    This meant that you put he parameters in the instruction
    stream right after the call to the subroutine.

    Here's the calling convention for your entertainment.

    1) The calling program would put the parameters into memory
    locations just past the call to the subroutine.
    2) Do a return-jump to the subroutine. This puts the return
    address in the first word of the subroutine and
    begins to execute the second word.
    3) Parameters are accessed by using and incrementing the
    return address.
    4) With the return address now safely stored in the first
    word of the subroutine, we can now return to the
    calling routine just by doing a indirect jump thru
    the first word of the routine.

    All this might not make sense to you so here is some code.
    This is CDC 1830 assembler, the best I can remember it.
    CDC 6600 works the same, but the code would be more
    confusing to the unfamiliar.


  6. Re: [9fans] Google search of the day

    On Fri, 15 Feb 2008 20:49:06 -0000, maht wrote:

    > for more analysis I suggest some online reading, I'm not deep enough
    > into either paradigm to offer suitable insights
    >


    Wisely said. I really have to read a lot before I understand the ideas you
    described. Only if the Finsler geometry course allows me ;-)

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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

    On Fri, 15 Feb 2008 23:39:40 -0000, Pietro Gagliardi
    wrote:

    > - DOS interrupt function calls use the registers, not the stack.
    > - SPARC and MIPS registers are provided to pass parameters.
    >
    > On Feb 15, 2008, at 6:37 PM, Lyndon Nerenberg wrote:
    >
    >>>
    >>> The calling conventions I have seen are the ccall, stdcall (Windows'
    >>> slightly modified version of the ccall), and pascal. All of them push
    >>> parameters on the stack.

    >>
    >> Take a look at the R-call and S-call conventions used on the IBM System
    >> 360 architecture. These machines didn't even have a stack.
    >>
    >> --lyndon

    >


    Good pieces of info. By the way, MS-DOS software interrupts were
    interrupts after all, i. e. different from procedure calls. Using the
    stack there would create re-entry problems (?) and a serious performance
    bottleneck (heh, MS-DOS to performance is Pumpkins to what?).

    On Sat, 16 Feb 2008 00:23:22 -0000, Brantley Coile
    wrote:

    > Early Control Data machines, like many machines
    > of the era, used the return address to fine the parameters.
    > This meant that you put he parameters in the instruction
    > stream right after the call to the subroutine.
    >
    > Here's the calling convention for your entertainment.
    >
    > 1) The calling program would put the parameters into memory
    > locations just past the call to the subroutine.
    > 2) Do a return-jump to the subroutine. This puts the return
    > address in the first word of the subroutine and
    > begins to execute the second word.
    > 3) Parameters are accessed by using and incrementing the
    > return address.
    > 4) With the return address now safely stored in the first
    > word of the subroutine, we can now return to the
    > calling routine just by doing a indirect jump thru
    > the first word of the routine.
    > All this might not make sense to you so here is some code.


    In fact, your explanation made much more sense than the code. To me, of
    course. The question of why would anyone devise such a weird scheme of
    calling procedures remains.

    > All the memory you would need was known as compile time.


    At the cost of transforming relocation into black magic. Were there
    binaries on that platform? Did those binaries need relocation? With code
    and data intermingled, there must have also been serious problems with
    minimizing binary sizes. All the "empty" words at the beginning of each
    subroutine had to be written to permanent storage, I guess. The x86 stack
    consumes zero space on permanent storage.

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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

    On Feb 16, 2008, at 6:32 PM, Eris Discordia wrote:

    > Using the stack there would create re-entry problems


    Under very specific conditions you can do

    PUSH Param1
    PUSH Param2
    PUSH Param3
    INT 80h

    What are those conditions?

    - Pascal calling convention
    - You save the registers before PUSHing the first argument

    For now, my OS does this as a temporary method of avoiding the
    necessity of managing different numbers of registers. This will
    change in due time!



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

    >> Early Control Data machines, like many machines
    >> of the era, used the return address to fine the parameters.
    >> This meant that you put he parameters in the instruction
    >> stream right after the call to the subroutine.
    >>
    >> Here's the calling convention for your entertainment.
    >>
    >> 1) The calling program would put the parameters into memory
    >> locations just past the call to the subroutine.
    >> 2) Do a return-jump to the subroutine. This puts the return
    >> address in the first word of the subroutine and
    >> begins to execute the second word.
    >> 3) Parameters are accessed by using and incrementing the
    >> return address.
    >> 4) With the return address now safely stored in the first
    >> word of the subroutine, we can now return to the
    >> calling routine just by doing a indirect jump thru
    >> the first word of the routine.
    >> All this might not make sense to you so here is some code.

    >
    > In fact, your explanation made much more sense than the code. To me, of
    > course. The question of why would anyone devise such a weird scheme of
    > calling procedures remains.


    This was the dawn of computer time, and the machines had few registers.
    The basic Wheeler Jump on the EDSAC, the first operational stored
    program computer, consisted of loading the address of the parameters
    following the jump into the accumulator before jumping to the subroutine.
    With so few registers, it is natural to use the return address
    to get at both the parameters and figure out where to return.

    In other words, this is what we did before we figured out a better way.

    Don't ask about index registers. (add 1 to the instruction and execute it.)


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

    >> All the memory you would need was known as compile time.
    >
    > At the cost of transforming relocation into black magic. Were there
    > binaries on that platform? Did those binaries need relocation? With code
    > and data intermingled, there must have also been serious problems with
    > minimizing binary sizes. All the "empty" words at the beginning of each
    > subroutine had to be written to permanent storage, I guess. The x86 stack
    > consumes zero space on permanent storage.


    The relocation formats for the 6600 assembler wasn't that complicated,
    much less than coff. For the Cyber 17/18 the instructions could
    be pc relative and didn't have to be relocated when linked together,
    at least not for the call/return scenario.

    The 6600 had a field address that was added to the program counter
    to relocate the program. It also had a field length register to
    make sure you didn't spill off the end.

    All was much simpler than today.


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

    On Sun, 17 Feb 2008 00:04:31 -0000, Brantley Coile
    wrote:

    > The relocation formats for the 6600 assembler wasn't that complicated,
    > much less than coff. For the Cyber 17/18 the instructions could
    > be pc relative and didn't have to be relocated when linked together,
    > at least not for the call/return scenario.


    I remember the necessity of relocation was not limited to where you had to
    link binaries. On the 80286 + MS-DOS combination, lack of virtual memory
    hardware (the "real" mode) made relocation inevitable as processes were
    not isolated and memory was not multiplexed by the hardware and/or OS.
    Without a flat and isolated address space for each process, every
    executable had to adjust to where it was being loaded. Hence, the EXE
    header and relocation table.

    COFF has had to cope with a certain monster dubbed portability; to adapt
    to the peculiarities of the many flavors of UNIX (and at least one
    Microsoft OS, with MS-COFF). So good it has been practically put out of
    business by ELF or... do Plan 9 compilers output COFF object files?

    > The 6600 had a field address that was added to the program counter
    > to relocate the program. It also had a field length register to
    > make sure you didn't spill off the end.


    No far jumps/calls? Was the memory model not segmented?

    > All was much simpler than today.


    I am actually very grateful for having a flat 32/64 bit address space all
    to myself. Even though the curse of managing virtual memory and driving
    the associated hardware has been placed on every OS developer, occasional
    programmers like me really enjoy the outcome.

    --
    Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

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

    > COFF has had to cope with a certain monster dubbed portability; to adapt
    > to the peculiarities of the many flavors of UNIX (and at least one
    > Microsoft OS, with MS-COFF). So good it has been practically put out of
    > business by ELF or... do Plan 9 compilers output COFF object files?


    see a.out(6).

    > COFF has had to cope with a certain monster dubbed portability; to adapt
    > to the peculiarities of the many flavors of UNIX (and at least one
    > Microsoft OS, with MS-COFF). So good it has been practically put out of
    > business by ELF or... do Plan 9 compilers output COFF object files?


    flat memory model:
    http://en.wikipedia.org/wiki/CDC_660...y_organization

    > I am actually very grateful for having a flat 32/64 bit address space all
    > to myself. Even though the curse of managing virtual memory and driving
    > the associated hardware has been placed on every OS developer, occasional
    > programmers like me really enjoy the outcome.


    it's interesting to note that it is being loaded at a constant address
    makes the job of loading & generating the code much simplier. the
    location of allocated memory isn't as important --- those details
    can often be hidden in an malloc-style function. even on 386
    hardware, segments can be used to cover all of memory. as long
    as your allocator knows where not to step (pci space, for example),
    this should be good enough.

    so if you're running without the operating system or your application
    is the operating system (embedded systems), virtual memory might
    just get in the way. tlb hardware doesn't do its translation for free.

    - erik


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

    On 2/17/08, Eris Discordia wrote:

    > do Plan 9 compilers output COFF object files?


    not typically, but some of the linkers can be instructed to. see the
    -Hn argument in 2l(1). the list of what the linkers can generate isn't
    documented, but look for HEADTYPE in /sys/src/cmd/[12578kqv]l/obj.c. i
    haven't had a machine to try the output on in several years, but vl's
    documented ability to produce IRIX coff executables at least used to
    work.

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

    > so if you're running without the operating system or your application
    > is the operating system (embedded systems), virtual memory might
    > just get in the way. tlb hardware doesn't do its translation for free.


    Or if you have moved onto the greener pastures of Limbo... not having
    to worry about all this saves many headaches when you want to port
    Inferno to a new arch too.

    uriel

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

    >> do Plan 9 compilers output COFF object files?
    >


    never. ken thompson's paper tells enough, if not all.


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

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


    I found Russ's recent post about Duff's device and the PuTTY coroutine
    example that it referenced interesting:



    -Chad

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

    >> so if you're running without the operating system or your application
    >> is the operating system (embedded systems), virtual memory might
    >> just get in the way. tlb hardware doesn't do its translation for free.

    >
    > Or if you have moved onto the greener pastures of Limbo... not having
    > to worry about all this saves many headaches when you want to port
    > Inferno to a new arch too.
    >
    > uriel


    the world isn't this simple. just cause you've got the limbo hammer, doesn't
    mean all the world's a nail.

    porting limbo to a new architecture requires porting ken's toolchain
    and the inferno kernel. i don't see how a self-containted operating system/
    application would be less work to port.

    if the work you're doing is performance-sensitive enough that tlb misses
    make a difference, then you certainly do not want to pay the penalty of
    a virtual machine.

    further, if the work you're doing is in the kernel or kernel-level, unless you
    have hardware implemting dis, you can't write this in a language like limbo
    which targets a virtual machine.

    - erik


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

    how did this get past my erik filter?

    wrong, wrong, wrong, wrong.

    four out of four as expected.

    brucee

    On Feb 18, 2008 10:58 AM, erik quanstrom wrote:
    > >> so if you're running without the operating system or your application
    > >> is the operating system (embedded systems), virtual memory might
    > >> just get in the way. tlb hardware doesn't do its translation for free.

    > >
    > > Or if you have moved onto the greener pastures of Limbo... not having
    > > to worry about all this saves many headaches when you want to port
    > > Inferno to a new arch too.
    > >
    > > uriel

    >
    > the world isn't this simple. just cause you've got the limbo hammer, doesn't
    > mean all the world's a nail.
    >
    > porting limbo to a new architecture requires porting ken's toolchain
    > and the inferno kernel. i don't see how a self-containted operating system/
    > application would be less work to port.
    >
    > if the work you're doing is performance-sensitive enough that tlb misses
    > make a difference, then you certainly do not want to pay the penalty of
    > a virtual machine.
    >
    > further, if the work you're doing is in the kernel or kernel-level, unless you
    > have hardware implemting dis, you can't write this in a language like limbo
    > which targets a virtual machine.
    >
    > - erik
    >
    >


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

    > how did this get past my erik filter?
    >
    > wrong, wrong, wrong, wrong.
    >
    > four out of four as expected.
    >
    > brucee


    100% whinage. 0 justification. 0 information. par for the course. ☺

    since you disagree, i assume you claim that limbo's the hammer and all
    computing problems are nails. i'd like to know why limbo's the right
    thing to run, e.g., on a freescale hc08 microcontroller. i'd also like to know
    why there is no performance penalty for running dis code over c. do
    you claim the garbage collection doesn't take any appreciable time?
    and the there is no overhead dealing with limbo's runtime typechecking?
    the inferno kernel i know about is written in c. where's the limbo version?
    how does one run a limbo program on a new architecture without porting
    the runtime or jit?

    - erik


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

    One more thing:

    On Feb 17, 2008, at 6:58 PM, erik quanstrom wrote:

    > porting limbo to a new architecture requires porting ken's toolchain
    > and the inferno kernel.


    /n/sources/contrib/pietro/limbo.tgz

    The only thing ported was the source code and mkfiles.



+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast