[9fans] FP register usage in Plan9 assembler

[9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

I'm studying the 9front's amd64 kernel, and I'm pretty new to assembler
programming, so sorry if my question is too dumb...

I cannot understand the FP pseudo register usage.
The cpuid function, for example, is implemented as

/*
 * The CPUID instruction is always supported on the amd64.
 */
TEXT cpuid(SB), $-4
    MOVL    RARG, AX            /* function in AX */
    CPUID

    MOVQ    info+8(FP), BP
    MOVL    AX, 0(BP)
    MOVL    BX, 4(BP)
    MOVL    CX, 8(BP)
    MOVL    DX, 12(BP)
    RET

What I miss is where "info" comes from. I cannot

Apparently the GAS equivalent is:

.align 4
.globl cpuid
cpuid:
    mov    %ebp,%eax
    cpuid
    mov    0x10(%rsp),%rbp
    mov    %eax,0x0(%rbp)
    mov    %ebx,0x4(%rbp)
    mov    %ecx,0x8(%rbp)
    mov    %edx,0xc(%rbp)
    retq

Thus apparently info+8(FP) becomes 0x10(%rsp)
Why? I know that FP is a pseudo register, but shouldn't it be different
from SP?

And why info's value is 8? Is it the pointer size?

Another example:

TEXT insb(SB), 1, $-4
    MOVL    RARG, DX            /* MOVL    port+0(FP), DX */
    MOVQ    address+8(FP), DI
    MOVL    count+16(FP), CX
    CLD
    REP;    INSB
    RET

should be equivalent to

.align 4
.globl insb
insb:
    mov    %ebp,%edx
    mov    0x10(%rsp),%rdi
    mov    0x18(%rsp),%ecx
    cld
    rep insb
    retq

Again I cannot find a definition of address and count, but both seem to be
be valued as 8, why?


Giacomo

[-- Attachment #2: Type: text/html, Size: 2516 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On 1 February 2016 at 16:47, Giacomo Tesio <giacomo@tesio.it> wrote:

>     MOVQ    info+8(FP), BP
>     MOVL    AX, 0(BP)
>     MOVL    BX, 4(BP)
>     MOVL    CX, 8(BP)
>     MOVL    DX, 12(BP)
>     RET
>
> What I miss is where "info" comes from.
>

the syntax name+offset(FP) defines name as the given offset from the
virtual frame pointer.
The actual offset in machine code is set by the loader (8l, 6l, etc.),
after taking account of the save area size, for example.
The name is stored in a symbol table mainly for use by the debugger.

[-- Attachment #2: Type: text/html, Size: 1027 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

On 1 February 2016 at 22:38, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> the syntax name+offset(FP) defines name as the given offset from the
> virtual frame pointer.


I ought to have added that it's +8 because info is the second parameter,
where the parameter space is
divided into slots of 8 bytes on amd64 and 4 bytes on the 32-bit
architectures. on amd64, the first parameter is passed in a register (BP);
as on some of the RISC machines. on amd64, the second parameter is +8(FP),
third is +16(FP), and so on.
 on x86/32 the first parameter is passed on the stack, so it's +0(FP),
+4(FP), ...

[-- Attachment #2: Type: text/html, Size: 1036 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[cinap_lenrek]

FP is a translated to a varying offset to SP depending on where in the program
you are. arguments on the stack are padded to 8 bytes on amd64, the first argument
is not passed on the stack on function entry, but passed in BP register (RARG is an
alias for that), however the slot on the stack for first arg is still reserved
so we have a save place to splill it. so 0(FP) is first function argument on the
stack, 8(FP) second argument 16(FP) third ect...

--
cinap

Re: [9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

Thanks for the explainations!

I did read in the Pike's paper about the syntax name+offset(FP), but I did
understood that name had to be a symbol already defined, and I was looking
for it in the c code. Sorry for the noise!

This led me to another question, however: I've read before that the plan9
compilers use the stack for va_list, but here the assembler is using it
also for explicit parameters, right?

Is it correct to say that this means that the Plan9 compiler suite *never*
follows the sysV calling convention documented at section 3.2.3 of AMD64
ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
parameters to the stack?


Giacomo



2016-02-01 23:48 GMT+01:00 <cinap_lenrek@felloff.net>:

> FP is a translated to a varying offset to SP depending on where in the
> program
> you are. arguments on the stack are padded to 8 bytes on amd64, the first
> argument
> is not passed on the stack on function entry, but passed in BP register
> (RARG is an
> alias for that), however the slot on the stack for first arg is still
> reserved
> so we have a save place to splill it. so 0(FP) is first function argument
> on the
> stack, 8(FP) second argument 16(FP) third ect...
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 1680 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On 1 February 2016 at 23:34, Giacomo Tesio <giacomo@tesio.it> wrote:

>
> Is it correct to say that this means that the Plan9 compiler suite *never*
> follows the sysV calling convention documented at section 3.2.3 of AMD64
> ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
> parameters to the stack?


On amd64, the first parameter, if an integer, is passed in RARG, which is
actually BP.
The RISC machines generally pass the first parameter, if an integer, in a
register.

In general, the compiler suite never follows conventions prescribed by
apparent maniacs.
In particular, varargs/stdargs should (in 2000, let alone 2016) be really
easy: lay down the ... parameters on the stack as an array in memory.
Done. Instead ABIs give pages of filth that try to work out where things
are for the va_x macro calls,
because the ABI insists on following the same calling convention
for vararg/stdarg functions as might be used for other functions with fixed
parameters: parameter passing in registers, special rules for structs,
special rules for structs that fit in the parameter registers, special
rules for floating-point values. Absurd.

[-- Attachment #2: Type: text/html, Size: 1724 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[Giacomo Tesio]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

I kinda agree, but I'm too incompetent in the matter. :-)

However, I was simply asking if, on amd64, kencc uses the 6 registers that
the abi deserves to the parameters.
As far as I've understood only BP is used (for the first argument, if
integer).

Can you confirm?



Giacomo

2016-02-02 1:36 GMT+01:00 Charles Forsyth <charles.forsyth@gmail.com>:

>
> On 1 February 2016 at 23:34, Giacomo Tesio <giacomo@tesio.it> wrote:
>
>>
>> Is it correct to say that this means that the Plan9 compiler suite
>> *never* follows the sysV calling convention documented at section 3.2.3 of
>> AMD64 ABI http://www.x86-64.org/documentation/abi.pdf and always pushes
>> parameters to the stack?
>
>
> On amd64, the first parameter, if an integer, is passed in RARG, which is
> actually BP.
> The RISC machines generally pass the first parameter, if an integer, in a
> register.
>
> In general, the compiler suite never follows conventions prescribed by
> apparent maniacs.
> In particular, varargs/stdargs should (in 2000, let alone 2016) be really
> easy: lay down the ... parameters on the stack as an array in memory.
> Done. Instead ABIs give pages of filth that try to work out where things
> are for the va_x macro calls,
> because the ABI insists on following the same calling convention
> for vararg/stdarg functions as might be used for other functions with
> fixed parameters: parameter passing in registers, special rules for
> structs, special rules for structs that fit in the parameter registers,
> special rules for floating-point values. Absurd.
>

[-- Attachment #2: Type: text/html, Size: 2477 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[Aram Hăvărneanu]

Yes, on Plan 9, on amd64, only one register is used (as explained by
Charles). Go doesn't use any registers for argument passing (even on
Plan 9).

You can just run 6c -S to see these things yourself.

-- 
Aram Hăvărneanu

Re: [9fans] FP register usage in Plan9 assembler

[Steven Stallion]

Hi Giacomo,

It's probably worth mentioning that learning assembly using the Plan 9
assembler is probably a bad idea. *a makes heavy use of pseudo
instructions and registers and unless you're well versed in its
quirks, can be very confusing when looking at more common assembly
dialects. Many instructions are directly encoded in the instruction
stream, largely due to the fact that it is more difficult than it
should be to extend the assembler as architectures evolve*. More
mechanically, Plan 9 makes use of a loader, which causes a number of
operations you would expect to be present in the assembler to be
deferred until later.

None of this is intended to dissuade of course, but as always in Plan
9: caveat emptor.

If you haven't looked already, a good place to start is /sys/doc/asm.ms.

Cheers,

Steve

* The diff to update support for ARMv7-A to 5a came in at over 2800
lines; this was to add a handful of instructions.

On Mon, Feb 1, 2016 at 10:47 AM, Giacomo Tesio <giacomo@tesio.it> wrote:
> I'm studying the 9front's amd64 kernel, and I'm pretty new to assembler
> programming, so sorry if my question is too dumb...
>
> I cannot understand the FP pseudo register usage.
> The cpuid function, for example, is implemented as
>
> /*
>  * The CPUID instruction is always supported on the amd64.
>  */
> TEXT cpuid(SB), $-4
>     MOVL    RARG, AX            /* function in AX */
>     CPUID
>
>     MOVQ    info+8(FP), BP
>     MOVL    AX, 0(BP)
>     MOVL    BX, 4(BP)
>     MOVL    CX, 8(BP)
>     MOVL    DX, 12(BP)
>     RET
>
> What I miss is where "info" comes from. I cannot
>
> Apparently the GAS equivalent is:
>
> .align 4
> .globl cpuid
> cpuid:
>     mov    %ebp,%eax
>     cpuid
>     mov    0x10(%rsp),%rbp
>     mov    %eax,0x0(%rbp)
>     mov    %ebx,0x4(%rbp)
>     mov    %ecx,0x8(%rbp)
>     mov    %edx,0xc(%rbp)
>     retq
>
> Thus apparently info+8(FP) becomes 0x10(%rsp)
> Why? I know that FP is a pseudo register, but shouldn't it be different from
> SP?
>
> And why info's value is 8? Is it the pointer size?
>
> Another example:
>
> TEXT insb(SB), 1, $-4
>     MOVL    RARG, DX            /* MOVL    port+0(FP), DX */
>     MOVQ    address+8(FP), DI
>     MOVL    count+16(FP), CX
>     CLD
>     REP;    INSB
>     RET
>
> should be equivalent to
>
> .align 4
> .globl insb
> insb:
>     mov    %ebp,%edx
>     mov    0x10(%rsp),%rdi
>     mov    0x18(%rsp),%ecx
>     cld
>     rep insb
>     retq
>
> Again I cannot find a definition of address and count, but both seem to be
> be valued as 8, why?
>
>
> Giacomo
>

Re: [9fans] FP register usage in Plan9 assembler

[lucio]

> If you haven't looked already, a good place to start is /sys/doc/asm.ms.

The Go release has revamped assembler documentation.  I haven't
inspected it myself, but the discussion around it suggests that it is
a much improved version of the original Bell Labs documents.

The focus is Go, of course, with the appropriate adjustments.  Today
that should not be much of a drawback.

Lucio.

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

On Tue Feb  2 08:43:47 PST 2016, sstallion@gmail.com wrote:
> Hi Giacomo,
>
> It's probably worth mentioning that learning assembly using the Plan 9
> assembler is probably a bad idea. *a makes heavy use of pseudo
> instructions and registers and unless you're well versed in its
> quirks, can be very confusing when looking at more common assembly
> dialects. Many instructions are directly encoded in the instruction
> stream, largely due to the fact that it is more difficult than it
> should be to extend the assembler as architectures evolve*. More
> mechanically, Plan 9 makes use of a loader, which causes a number of
> operations you would expect to be present in the assembler to be
> deferred until later.

hi, steve!

i've found the plan 9 assemblers to be straight-forward enough.  i love
the consistency from one architecture to another.  i like the fact that
there are so few meta-directives, and i do like the fact that the linker
will do the obvious rearrangments of plan 9 assembly, including automatic
delay slot filling, and other such fiddly bits.

obviously, this is just an opinion, so ymmv.

i think this is off the original point, but as to modifying the assmbler.
to add a new instruction, the linker, assembler and libmach need modification.
typically this is a matter of adding a line to each one for assembly, linking,
and disassembly, respecively.  it's worth looking at the addition of the ymm,
and then zmm registers and those patterns to 6[al] and libmach.  this is an
example of adding a new instruction encoding to an existing arch.

> * The diff to update support for ARMv7-A to 5a came in at over 2800
> lines; this was to add a handful of instructions.

do you perhaps mean the linker?

the pi kernels, which supports v6 (original) and v7 (pi2) rely on small asm
files for arch-specific functions.  i think you provided some explaination of
why this approach would not work for v5, but unfortunately, i don't remember
it.

- erik

Re: [9fans] FP register usage in Plan9 assembler

[Steven Stallion]

On Wed, Feb 3, 2016 at 9:24 AM, erik quanstrom <quanstro@quanstro.net> wrote:

> i think this is off the original point, but as to modifying the assmbler.
> to add a new instruction, the linker, assembler and libmach need modification.
> typically this is a matter of adding a line to each one for assembly, linking,
> and disassembly, respecively.  it's worth looking at the addition of the ymm,
> and then zmm registers and those patterns to 6[al] and libmach.  this is an
> example of adding a new instruction encoding to an existing arch.
>
>> * The diff to update support for ARMv7-A to 5a came in at over 2800
>> lines; this was to add a handful of instructions.
>
> do you perhaps mean the linker?
>
> the pi kernels, which supports v6 (original) and v7 (pi2) rely on small asm
> files for arch-specific functions.  i think you provided some explaination of
> why this approach would not work for v5, but unfortunately, i don't remember
> it.

The patch ended up in the usual place on sources. The patch itself
modernized all of the v7-A ports (this pre-dated the pi2 port by a
couple of years) to support common instructions rather than cramming
opcodes into the instruction stream. The exynos port relied on it
heavily since the Cortex-A15 required a bit more special handling than
the simpler cores in the omap, pi2, and teg2 ports. As you mentioned,
5[al], libmach, even acid were updated. You really can't touch one
thing without modifying everything else.

WRT to drawbacks in the loader for writing assembly, one of the
biggest problems is merciless optimization that cannot be disabled on
a per translation-unit basis (we're using a loader, remember?) As an
example, it's damned near impossible to perform PC-relative branching
in the vector table. Instead you end up having to the slower (and
sillier) load method that exists today.

As far as consistency between architectures go, it's a non-goal for
me. C is my portability layer - odds are very good that if I need to
dip into assembly, I need complete control over the instruction
stream.

Steve

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> WRT to drawbacks in the loader for writing assembly, one of the
> biggest problems is merciless optimization that cannot be disabled on
> a per translation-unit basis (we're using a loader, remember?) As an
> example, it's damned near impossible to perform PC-relative branching
> in the vector table. Instead you end up having to the slower (and
> sillier) load method that exists today.

profiling can be disabled on a per function basis, so it would be
a small amount of effort confined to the linker to add a per-function
optimization disable. it would not require a change to the asm grammar,
as another bit in the profile-disable field could be used.

can you explain exactly what optimization that is causing trouble, and
do you have timing information on both methods?

> opcodes into the instruction stream. The exynos port relied on it
> heavily since the Cortex-A15 required a bit more special handling than
> the simpler cores in the omap, pi2, and teg2 ports. As you mentioned,

the typical case of adding an opcode is easy.  /n/atom/patch/applied2013/6l8laes
adds 4 opcodes with 7 lines in a table (with a comment and a blank line).
i see the arm refresh patch adds 12 to the analogous file in 5l.

but it also aliases R14 to LC and bubbles that change through (etc), which
may explain the line count.

> 5[al], libmach, even acid were updated. You really can't touch one

i was confused at first by this claim, since acid has not architecture-
dependent code.  but you mean /sys/lib/acid/arm, an acid script.
none of those changes were required by additional instructions.

thanks for the patch, btw!  i have made use of a number of parts of it.

- erik

Re: [9fans] FP register usage in Plan9 assembler

[Aram Hăvărneanu]

On Wed, Feb 3, 2016 at 4:24 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> i love the consistency from one architecture to another.

Just like how different architectures use different order for CMP
arguments. Very consistent.

Or just how some architectures use typed registers, and some use
different-sized instruction variants.

Or just how most instructions use left-to-right dataflow order, some
instructions use right-to-left.

I could go on. Plan 9 assembly is nice because it looks mostly the
same, and the simple addressing modes are mostly consistent, but it's
far from being really consistent between architectures.

-- 
Aram Hăvărneanu

Re: [9fans] FP register usage in Plan9 assembler

[lucio]

> Plan 9 assembly is nice because it looks mostly the
> same, and the simple addressing modes are mostly consistent, but it's
> far from being really consistent between architectures.

Personally, I agree with the view that trying to generalise assemblers
across platforms is chasing a chimera.  I loved the Univac assembler I
cut my teeth on and nothing has ever given me even a hint of the
comfort I found there.  But I got used to the 8088 assembler and
managed to do some convincing work with it (I won't list the number of
issues I thought were total mindlessness by a crowd of engineers with
no visible theoretical background).

On today's platforms, assembler is not an option, it is a nightmare.
Add all the hardware trickery that belongs to microprocessors, not to
an adult computer, doesn't make anything more palatable.  Really, why
should the job of arranging memory on start up belong in the kernel
and not in a piece of dedicated logic that gets the job done and then
gets out of the way permanently, preferably switches off?

One of these day some hardware engineer will figure a way to move the
logic of the power supply into the CPU.  No, wait, we already have
voltage selections at different temperature as a kernel function, I
believe!

Bottom line?  Bless the Go Gods for having successfully subverted much
of this nonsense by providing a cross-platform development tool that
actually does what it says on the tin, despite efforts by the hardware
suppliers to relegate software development (the real thing, not
kid-scripting - or is it script-kidding?) to the smallest viable elite
of life-challenged droids.

I really do feel better now, doctor!

Lucio.

Re: [9fans] FP register usage in Plan9 assembler

[Brantley Coile]

Which plan 9 assembler uses right to left argument assignments, or compare argument order? I was not aware of inconsistency in syntax between assemblers. 

Maybe there is confusion between the use, in the different posts, between the macro architecture and the versions of the assembler, referred to as architecture. 

Or the confusion is about what Plan 9 is meant to be. The idea was to have a single system made of many different machines of a diverse set of architectures. A single system would have a single assembly language. The architectures are still different, but as much as possible the accidental differences between the assembly languages of the processor manufacturers are eliminated. The idea is not just to be a cross compiling system for embedded targets or is it to be a single machine system that ran on different hardware, but to be a single system running on a cloud of machines, to borrow some marketing jargon.

To that end, the Plan 9 syntax is fine for teaching assembler. And so doing, a person is better able to write good C code. The only disadvantage is when learning the assembler one has to translate front the manufacturer's documentation and the Plan 9 standard syntax. 

  Brantley Coile

Sent from my iPad

> On Feb 4, 2016, at 5:08 AM, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
> 
>> On Wed, Feb 3, 2016 at 4:24 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> i love the consistency from one architecture to another.
> 
> Just like how different architectures use different order for CMP
> arguments. Very consistent.
> 
> Or just how some architectures use typed registers, and some use
> different-sized instruction variants.
> 
> Or just how most instructions use left-to-right dataflow order, some
> instructions use right-to-left.
> 
> I could go on. Plan 9 assembly is nice because it looks mostly the
> same, and the simple addressing modes are mostly consistent, but it's
> far from being really consistent between architectures.
> 
> -- 
> Aram Hăvărneanu
> 

Re: [9fans] FP register usage in Plan9 assembler

[lucio]

> To that end, the Plan 9 syntax is fine for teaching assembler.  And
> so doing, a person is better able to write good C code.  The only
> disadvantage is when learning the assembler one has to translate front
> the manufacturer's documentation and the Plan 9 standard syntax.

I think too much depends on the perception of a need to use assembly.
If you start from the assumption that assembly can be relegated to
pin-point optimisation on one hand and architecture-focused
instructions on the other, that leaves a huge space in the middle
where one can use a more human notation to represent abstractions.

But when you cannot escape needing to use architecture-dependent
coding for abstract concepts, the battle is irreversibly lost.  Even,
maybe especially, Plan 9 gecomes an easily resisted force trying to
shift an immovable object.

Lucio.

Re: [9fans] FP register usage in Plan9 assembler

[Aram Hăvărneanu]

Brantley Coile <brantleycoile@me.com> wrote:
> Which plan 9 assembler uses right to left argument assignments,
> or compare argument order?

The CMP order is different (at least) between power and arm64. This
inconsistency is impossible to fix; I know because I tried to fix
it in the SPARC64 Go port.

The problem is that different architectures treat immediate constants
either as the first, or the second argument. For non-commutative
operations like subtractions, this matters.

However, in Plan 9, for three-argument instructions, we want to
have a two argument variant that works like this:

    OP      one, two -> OP    one, two, two

That is, the last argument is doubled, and serves as the (Plan 9)
second operand.

However, this means immediates must come first, because

    OP      $imm, R -> OP   $imm, R, R

makes sense, but

    OP      R, $imm, $imm

doesn't; $imm can't serve as destination.

So this forces immediates in Plan 9 assembly to be the first operands,
even though the machine might treat them as the first, or second
operands.

One might be tempted to allow immediates as second operands, and
simply forbit an instruction of the form "OP   R, $imm", mandating
one should always use the three-operand form "OP Rs, $imm, Rd".
Indeed this was what I did with the SPARC64 Go port. However, this
makes the compiler significantly more complex, and different, so
it's not a good idea.

As for instructions with different data flow order, atomic instructions
on ARM64 come to mind. Note that printing is still in "from, reg,
from3, to" order, so printing these instructions (7a -S) will print
something different than the input. This has been fixed in Go.

-- 
Aram Hăvărneanu

Re: [9fans] FP register usage in Plan9 assembler

[Aram Hăvărneanu]

To add some more on my previous post, yes, there are inconsistencies,
but the common syntax still help tremendously, so much that
translating between power and arm64 assembly has been mostly achieved
through sam(1).

-- 
Aram Hăvărneanu

Re: [9fans] FP register usage in Plan9 assembler

[Aram Hăvărneanu]

(Totally unrelated to the original post, but hey, we've already
left that path, so why not?)

Speaking of the Plan 9 toolchain, I much prefer the way it works
internally compared to the Go toolchain because it is much easier
to re-target. I haven't ported the Plan 9 toolchain (only saw Charles
do it), but I did port the Go toolchain twice, once for arm64, and
once for sparc64; once in C, and once in Go.

In Plan 9 porting is easy because the assembler, the compiler, and
the loader are all separate programs. Apart from trivial things
like a.out.h, they are completely independent. One could work on
them in any order. Better yet, the compiler can generate object
files before the loader is ready, and when the loader is finally
ready, it can just consume these already-produced object files.

Alternativelly, one can have the assembler ready very quickly, and
write enough of a libc so he can test the compiler when that is
written.

In Go it's not like this. The assembler, compiler, and linker all
link against a library which does roughly what the Plan 9 loader
does. This means that you have to have this working in some capacity
before you can start the other programs.

But this library is very hard to test since you don't have an
assembler yet.

Even worse, once you wrote enough of this library to have the
assembler and compiler produce some kind of output, you still can't
test anything because you need a runtime.

But the runtime is written in Go, so now you have to write large
quantities of Go and tricky assembly, without having the possibilty
to test anything, and while using a broken compiler (since the
compiler has not ran a single program yet, it's bound to be broken).

This tightly-coupled design makes development very difficult. Having
it done twice (actually three times), I'd say it's about 7x-10x
more work to re-target the Go toolchain than it is to re-target the
Plan 9 toolchain.

Mind you, compared to gcc and clang, 7x-10x more work is still
pretty good...

-- 
Aram Hăvărneanu

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> I think too much depends on the perception of a need to use assembly.
> If you start from the assumption that assembly can be relegated to
> pin-point optimisation on one hand and architecture-focused
> instructions on the other, that leaves a huge space in the middle
> where one can use a more human notation to represent abstractions.
>
> But when you cannot escape needing to use architecture-dependent
> coding for abstract concepts, the battle is irreversibly lost.  Even,

splhi(), and splx() (see splhi(9), which enable and disable interrupts, are
abstract concepts that are neither optimization, nor are able to be expressed
in c.  there is no harm done by this pattern.  it simply is the way things are.

- erik

Re: [9fans] FP register usage in Plan9 assembler

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On 4 February 2016 at 12:24, Brantley Coile <brantleycoile@me.com> wrote:

> Which plan 9 assembler uses right to left argument assignments, or compare
> argument order


For example, the ARM's MCR and MRC instructions are unchanged from the
manufacturer's order.
Partly that's because the "instructions" are really just encoding a set of
fields that happen to include one or two processor
registers that might or might not be accessed. Those are the only ones I
can think of off-hand, but there might be others.
On PowerPC, even LWAR ("load") and STWCCC keep to the data-flow order,
though.

CMP on some RISC architectures keeps the order of the underlying
subtract-discarding-result that it represents.
Perhaps they all do it. When I've done a new architecture, I try to keep
the feel of similar architectures (RISC or CISC).

The typed registers vs typed instructions was originally easy: integer
operations used the same register names (eg, typically Rn, but also AX, DX,
...) and the instruction was byte/word/long, instead of encoding lengths as
in %ax vs %eax (but of course x86 has to have AL, AH, etc for compatibility
with 8086). Floating point registers had their own name, but the
instructions still had a type, so it was ADDF or FADD not
just ADD F0, ... . Then vectors and logical registers nested inside
physical ones or aliasing them appeared, and now even the RISCs
have instructions with a result type but possibly different types for each
operand.

Note though that although the terms "assembler" and "loader" are used,
the whole scheme starts with the use of an abstract syntax of a given
architecture for use by the compilers.
The assembler is just a readable version of that abstract syntax, that's
vaguely like a conventional assembler
including the funky upper case names. It could be S-expressions.

I still quite like the distribution of work, for the reasons Aram just gave.
Latterly, I've been making the things a little smaller and perhaps simpler,
by continuing some changes that
Russ made (eg, pgen.c pswt.c) to reduce the amount of almost identical code
that's replicated across the suites.

[-- Attachment #2: Type: text/html, Size: 3070 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> Or just how some architectures use typed registers, and some use
> different-sized instruction variants.

which architeture uses typed registers?  a quick check of 386, 68020,
alpha, arm, mips, power, power64, sparc, and amd64 shows all use
MOV[WLQ].

- erik

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> I still quite like the distribution of work, for the reasons Aram just gave.
> Latterly, I've been making the things a little smaller and perhaps simpler,
> by continuing some changes that
> Russ made (eg, pgen.c pswt.c) to reduce the amount of almost identical code
> that's replicated across the suites.

thanks for that!

- erik

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

On Thu Feb  4 07:15:03 PST 2016, quanstro@quanstro.net wrote:
> > Or just how some architectures use typed registers, and some use
> > different-sized instruction variants.
>
> which architeture uses typed registers?  a quick check of 386, 68020,
> alpha, arm, mips, power, power64, sparc, and amd64 shows all use
> MOV[WLQ].

i see charles has answered this.  and the issue is mostly with corner cases,
and architectural oddities.

MOVQQU or MOVQQA still follow the expected pattern.

- erik

Re: [9fans] FP register usage in Plan9 assembler

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

On 4 February 2016 at 15:22, erik quanstrom <quanstro@quanstro.net> wrote:

> MOVQQU or MOVQQA still follow the expected pattern.


Originally on amd64 I consistently used O instead of sometimes DQ and
sometimes O as Intel did,
but in the end I changed them back to the Intel names, since it was hard to
look them up,
and there were so many.

[-- Attachment #2: Type: text/html, Size: 694 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[Ryan Gonzalez]

On February 4, 2016 6:04:49 AM CST, lucio@proxima.alt.za wrote:
>> Plan 9 assembly is nice because it looks mostly the
>> same, and the simple addressing modes are mostly consistent, but it's
>> far from being really consistent between architectures.
>
>Personally, I agree with the view that trying to generalise assemblers
>across platforms is chasing a chimera.  I loved the Univac assembler I
>cut my teeth on and nothing has ever given me even a hint of the
>comfort I found there.  But I got used to the 8088 assembler and
>managed to do some convincing work with it (I won't list the number of
>issues I thought were total mindlessness by a crowd of engineers with
>no visible theoretical background).
>
>On today's platforms, assembler is not an option, it is a nightmare.
>Add all the hardware trickery that belongs to microprocessors, not to
>an adult computer, doesn't make anything more palatable.  Really, why
>should the job of arranging memory on start up belong in the kernel
>and not in a piece of dedicated logic that gets the job done and then
>gets out of the way permanently, preferably switches off?
>
>One of these day some hardware engineer will figure a way to move the
>logic of the power supply into the CPU.  No, wait, we already have
>voltage selections at different temperature as a kernel function, I
>believe!
>
>Bottom line?  Bless the Go Gods for having successfully subverted much
>of this nonsense by providing a cross-platform development tool that
>actually does what it says on the tin, despite efforts by the hardware
>suppliers to relegate software development (the real thing, not
>kid-scripting - or is it script-kidding?) to the smallest viable elite
>of life-challenged droids.
>

*cough* that's what people said about Java *cough*

>I really do feel better now, doctor!
>
>Lucio.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

Re: [9fans] FP register usage in Plan9 assembler

[lucio]

> *cough* that's what people said about Java *cough*

What, that Java does what it says on the tin? Which tin?

Lucio.

Re: [9fans] FP register usage in Plan9 assembler

[Ryan Gonzalez]

On February 4, 2016 10:09:49 AM CST, lucio@proxima.alt.za wrote:
>> *cough* that's what people said about Java *cough*
>
>What, that Java does what it says on the tin? Which tin?
>

cross-platform development tool

>Lucio.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

Re: [9fans] FP register usage in Plan9 assembler

[balaji]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

go without the packages will be as useful as java without class libraries.
nothing.
i'm happy they understood the table stakes for a new software/application
development language.
i can also see why they bundled all the compilation stages into one --
script kiddies don't do make files

On Thu, Feb 4, 2016 at 12:06 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:

>
>
> On February 4, 2016 10:09:49 AM CST, lucio@proxima.alt.za wrote:
> >> *cough* that's what people said about Java *cough*
> >
> >What, that Java does what it says on the tin? Which tin?
> >
>
> cross-platform development tool
>
> >Lucio.
>
> --
> Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
>
>

[-- Attachment #2: Type: text/html, Size: 1181 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[Ryan Gonzalez]

On February 4, 2016 10:09:49 AM CST, lucio@proxima.alt.za wrote:
>> *cough* that's what people said about Java *cough*
>
>What, that Java does what it says on the tin? Which tin?

Almost forgot:

The AbstractBeanPartAluminumRecyclableTinFactory that makes AbstractPartAluminumRecyclableTinLists, which contain AbstractPartAluminumRecyclableTins.

>
>Lucio.

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

Re: [9fans] FP register usage in Plan9 assembler

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

Limbo is a contemporary of Java and it has several key features that Go and
Java are known for; e.g. CSP and VM. The difference is that the level of
awareness and experience of developers is higher now than it was then.
Sadly, Inferno and Limbo are still underrated today.

On Thu, Feb 4, 2016 at 7:58 AM Ryan Gonzalez <rymg19@gmail.com> wrote:

>
>
> On February 4, 2016 6:04:49 AM CST, lucio@proxima.alt.za wrote:
> >> Plan 9 assembly is nice because it looks mostly the
> >> same, and the simple addressing modes are mostly consistent, but it's
> >> far from being really consistent between architectures.
> >
> >Personally, I agree with the view that trying to generalise assemblers
> >across platforms is chasing a chimera.  I loved the Univac assembler I
> >cut my teeth on and nothing has ever given me even a hint of the
> >comfort I found there.  But I got used to the 8088 assembler and
> >managed to do some convincing work with it (I won't list the number of
> >issues I thought were total mindlessness by a crowd of engineers with
> >no visible theoretical background).
> >
> >On today's platforms, assembler is not an option, it is a nightmare.
> >Add all the hardware trickery that belongs to microprocessors, not to
> >an adult computer, doesn't make anything more palatable.  Really, why
> >should the job of arranging memory on start up belong in the kernel
> >and not in a piece of dedicated logic that gets the job done and then
> >gets out of the way permanently, preferably switches off?
> >
> >One of these day some hardware engineer will figure a way to move the
> >logic of the power supply into the CPU.  No, wait, we already have
> >voltage selections at different temperature as a kernel function, I
> >believe!
> >
> >Bottom line?  Bless the Go Gods for having successfully subverted much
> >of this nonsense by providing a cross-platform development tool that
> >actually does what it says on the tin, despite efforts by the hardware
> >suppliers to relegate software development (the real thing, not
> >kid-scripting - or is it script-kidding?) to the smallest viable elite
> >of life-challenged droids.
> >
>
> *cough* that's what people said about Java *cough*
>
> >I really do feel better now, doctor!
> >
> >Lucio.
>
> --
> Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
>
>

[-- Attachment #2: Type: text/html, Size: 2899 bytes --]

Re: [9fans] FP register usage in Plan9 assembler

[erik quanstrom]

> > MOVQQU or MOVQQA still follow the expected pattern.
> >
>
> Originally on amd64 I consistently used O instead of sometimes DQ and
> sometimes O as Intel did, but in the end I changed them back to the
> Intel names, since it was hard to look them up, and there were so
> many.

ack.  typo in my post.  :-(.  it's too bad about DQ rather than O, but the
reasons make perfect sense.

- erik