profile
viewpoint

minux/goios 23

mirror of the iOS port of the Go programming language (ios3 is the 32-bit branch, ios64-new is the 64-bit branch) Go 1.5 will include both ports!

4ad/go.arm64 18

Go development tree for the arm64 port (historical).

4ad/go 12

Go development tree for the sparc64 port

minux/go-tour-zh 12

Go Tour (Chinese Translation)

minux/go-ios-examples 11

Trivial examples Go programs for the iOS port

minux/go-windows 4

some random windows related go features (or bugs?)

minux/cmph 2

CMPH - C Minimal Perfect Hashing Library (forked from http://cmph.sourceforge.net/)

minux/llgo 2

A fork of LLVM-based compiler for Go (llgo). Two branches (minux and minux2) are intended for upstream merging. All branches with a "temp_" prefix are made purely for preview of some of my work, and are subject to frequent forced update.

minux/cuckoo 1

a memory-bound graph-theoretic proof-of-work system

minux/go-arm64 1

Go development tree for the arm64 port (minirt is the replacement runtime branch, dev.arm64 is the main dev branch, cgo64.new is the cgo development branch)

startedazonenberg/scopehal-cmake

started time in 4 hours

startedvowstar/k210-linux-nommu

started time in 7 days

create barnchminux/iverilog

branch : issue306

created branch time in 19 days

push eventminux/iverilog

minux

commit sha 7de00ee73a1b7adf6f2764dfd28b4022f977cd45

Makefile.in: fix mkdir race during "make -j N install"

view details

Stephen Williams

commit sha 78f12dec1cb6e8638b94089be032c67f54df48b4

Merge pull request #294 from minux/fix-make-j-install Makefile.in: fix mkdir race during "make -j N install"

view details

Huang Rui

commit sha d49d26a5c502faf132a7a65e5cc7173ac0dfa1f5

Fix fails to build with -fno-common or gcc-10 See also: https://bugs.gentoo.org/706366 gcc-10 and above flipped a default from -fcommon to -fno-common: https://gcc.gnu.org/PR85678 Usually all it takes is to add a few 'extern' declarations and move definitions from header files to modules. I've port iverilog to gcc-10 accroding to this guide: https://wiki.gentoo.org/wiki/Gcc_10_porting_notes/fno_common To fix this, I analyzed the code, and found ``pli_trace`` has been defined at here: https://github.com/steveicarus/iverilog/blob/v10_3/libveriuser/priv.c#L24 So I changed ``FILE* pli_trace;`` to ``extern FILE* pli_trace;``. The var ``current_file`` only in ``cfparse_misc.h``, I changed it from ``char *current_file;`` to ``extern char *current_file;`` and declaring it in cflexor.lex And then it works. Signed-off-by: Huang Rui <vowstar@gmail.com>

view details

Martin Whitaker

commit sha 20d7309ec2f9984e3c43d3c55efced11eeb70d09

Merge pull request #302 from vowstar/vowstar-fix-gcc10. Fixes build with -fno-common (default in GCC 10).

view details

Martin Whitaker

commit sha 0023804777a674346a88cfe3a1c6c9bcee169f4b

Add support for increment/decrement operators in generate loop iteration. As requested in GitHub issue #303.

view details

Martin Whitaker

commit sha 33b822d9972984ab3dd4f71c444d957f6663ea8d

Add support for local genvar declaration in generate loops. As requested in GitHub issue #304.

view details

Martin Whitaker

commit sha b1114760fcfba55ee9ca35ba95e2b3ed2b7c7a20

Fix for compatibility with old C++ standard.

view details

push time in 19 days

pull request commentsteveicarus/iverilog

Fix iverilog files not update bug during overwrite installation

As mentioned earlier, prefixing $(DESTDIR) will only fix the case when $(DESTDIR) is specified and $(DESTDIR) points to an empty tree. And it will break for the regular "make; make install" scenario (when updating an previous installation). (see https://github.com/steveicarus/iverilog/pull/300#issuecomment-576009202 for an example.)

When installing, we must not consider the timestamp of the target files and must overwrite them unconditionally.

vowstar

comment created time in 24 days

pull request commentsteveicarus/iverilog

Fix iverilog files not update bug during overwrite installation

To summarize: If it's for a local patch in Gentoo portage, .PHONY solution would be the best, as it minimizes diff size and we can afford to include comments explaining this reason why .PHONY is needed. But for the upstream, we need a solution that is not only 100% correct but also with the least cognitive load and least error-prone for future changes.

vowstar

comment created time in a month

pull request commentsteveicarus/iverilog

Fix iverilog files not update bug during overwrite installation

The size of the PR seems large is only because each file is split into each own commit. Either of your proposed .PHONY or $(DESTDIR)-prefixing solutions will still change all 20 Makefiles, so with the one-file-per-commit organization, it will also result in 20 commits. Thus your point of simpler solution (in terms of commit count) doesn't hold.

Also, your list of real-world examples conveniently omit one of the more common usage scenarios where prefixing $(DESTDIR) fails. 3. the user regularly downloads source tarball and manually installs (updates) into /usr/local/.

If we have to fix the problem, let's fix it completely this time, not partially. And for 3, the problem with $(DESTDIR)-prefixing fix will lead to very subtle problems for the user (some of the headers file are silently not updated.)

The .PHONY solution is ok in this regard, but the only benefit it offers is that it enables parallel installation of multiple targets, and it's slightly simpler.

The reason I don't like .PHONY is that it's completely negates the benefit of providing the dependency information to make, and it's a unconventional usage of .PHONY, which is supposedly used to label targets that are not actually files/directories (like clean, install and installdirs). If make doesn't need the dependency for each installed file, then just don't provide it and list all installed files of the same kind under the recipe for each kind. The current PR is larger but is modeled after automake generated Makefiles, and it represents a generally accepted approach to this problem.

The other reason against .PHONY is that, we will need to include a comment explaining why we provide .POHNY for a file that actually exists, and it adds more cognitive load to future maintainers, otherwise, the maintainer might forget to add a new install file to .PHONY and reintroduce this problem. That's why I think .PHONY solution, while correct, is actually more error prone that the proposed approach. (Just imagine if you want to add to add a new installed file: The .PHONY solution requires you to add one more rule and also one more .PHONY declaration, but with this change, you just change the dependency of the appropriate rule and add one more line to its recipe. Which one is easier and less error prone? Not only is the 2nd one simpler, it also has less opportunity for errors.)

vowstar

comment created time in a month

pull request commentsteveicarus/iverilog

Fix iverilog files not update bug during overwrite installation

DESTDIR is only used for packaging, I agree. But with your proposed change, regular make install without DESTDIR will still exhibit incorrect behavior for the cases I showed. (Showing that there exists other incorrectly written Makefiles doesn't mean we have to join them, especially if there is a correct way to handle those cases.) The only correct way is to unconditionally overwrite all destination files while installing. There is no easy way to remove orphaned files, and the only reliable way to remove them is to run make uninstall from the original version. Hopefully the newly installed files should overwrite all existing files.

The installdirs fix could use order-only prerequisites, but I believe for this specific case, the difference doesn't matter in practice. (How could my change force rebuild all targets when directory timestamp is changed? It will only force reinstallation of the files when you run make install again, but that is exactly what you want when you do make install.)

vowstar

comment created time in a month

pull request commentsteveicarus/iverilog

Fix iverilog files not update bug during overwrite installation

prefixing targets with $(DESTDIR) won't work for tarball based source installation, and make uninstall before make install is also problematic.

Consider this timestamp sequence: release A: time t1, release A+1: time t2, t2 > t1

User at time t3 (t3 > t2) installs release A, but then found out release A+1 is out too, so it installs A+1. Because all installed files is at t3, none of the rule will be triggered, and the user will get outdated files on disk.

It's true that if the user runs make uninstall will likely fix this issue, but the problem is that, to be able to fully uninstall all files, the user can't just run make uninstall from release A+1, they have to run make uninstall from release A. This creates extra work without much benefits for the user.

I don't think prefixing $(DESTDIR) is how "all makefiles" basically works. (Nearly) all makefiles override all installations files unconditionally. And this is very different from prefixing $(DESTIDR) on the target path.

Of course, one way to solve the specific problem I mentioned with prefixing $(DESTDIR) would be to use install -p to preserve the timestamp. But then when the user wants to downgrade from release A+1 to release A, it still fails to update the files.

The takeaway is that: the install target should override all target files unconditionally.

vowstar

comment created time in a month

issue commentkendryte/kendryte-standalone-sdk

dvp_get_interrupt(uint32_t interrupt) takes lot of time to return

what if sensor_irq triggers twice per frame (one for start and another for finish)?

If you really want to measure the overhead of a call, use the mcycle CSR.

krishnak

comment created time in a month

issue commentkendryte/nncase

Quantized binary with high execution time

have you updated git submodules when cloning the repository? xtensor should be included as a submodule of nncase.

krishnak

comment created time in a month

issue closedgolang/go

^0 is interpreted as -1

What did you do?

https://play.golang.org/p/2kMDzm1vAtF

package main

import (
	"fmt"
)

func main() {
	var x uint64 = ^0
	fmt.Println(x)
}

What did you expect to see?

I expected it to print the highest uint64 value possible

What did you see instead?

./prog.go:8:17: constant -1 overflows uint64

The logical complement of 0 should not be assumed to be signed.

closed time in a month

kstenerud

issue commentgolang/go

^0 is interpreted as -1

Need to use ^uint64(0) as explained https://blog.golang.org/constants#TOC_11%2e

kstenerud

comment created time in a month

PR opened steveicarus/iverilog

Makefile.in: fix mkdir race during "make -j N install"

Without the dependency on installdirs, when running make -j N DESTDIR=/somewhere install, those file installation targets might run concurrently with the mkinstalldirs target, which might lead to file not found errors.

For example:

$ make -j24 DESTDIR=/var/tmp/portage/sci-electronics/iverilog-10.3/image install
....
mkdir -p -- /var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/bin /var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/include/iverilog /var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/lib64/ivl /var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/lib64/ivl/include /var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/share/man /var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/share/man/man1
/usr/bin/install: cannot create regular file '/var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/lib64/ivl/include/disciplines.vams': No such file or directory
/usr/bin/install: cannot create regular file '/var/tmp/portage/sci-electronics/iverilog-10.3/image/usr/lib64/ivl/ivl': No such file or directory
make: *** [Makefile:345: /usr/lib64/ivl/include/disciplines.vams] Error 1
+12 -12

0 comment

1 changed file

pr created time in 2 months

push eventminux/iverilog

Stephen Williams

commit sha f657d1d7d7abef257e708fe91ab03e79181352d0

Revert "Update vtype.cc" This reverts commit 49515ff62b8b2567fe1cb665bf866c0900dc40bb.

view details

Stephen Williams

commit sha 540bb5afa69a38bd0d3f6eba143fa0fa7a538db1

Revert "Update parse_misc.cc" This reverts commit 6d06e9351acb847fcfc9f79ceafe960c3531b06e.

view details

Stephen Williams

commit sha 6c7495c93e3fd6ec6de6c427141ee33d5341cc27

Merge branch 'master' of github.com:steveicarus/iverilog

view details

Stephen Williams

commit sha c37d6ac3ac459f7be029c5e91053819f3749c436

Merge branch 'master' of github.com:steveicarus/iverilog Conflicts: vhdlpp/parse_misc.cc vhdlpp/vtype.cc

view details

Yury Gribov

commit sha 43cd693fe07b16467b2d66cc9678dfcb63ff485c

Put start events to proper queue.

view details

Thomas Fors

commit sha 3afbb903d63973b8b81ab6a02dd7be0e950e6982

Use /proc/self/exe on linux, if it exists, to find ivl_root

view details

Thomas Fors

commit sha cada40ebd119b9a38878211f495ed1716aa01502

Updated comments

view details

Martin Whitaker

commit sha b8f9ed27c5f91496693260563adae142eaa3abc5

Fix for br1003 - prevent segfault when delays are used outside a module.

view details

Martin Whitaker

commit sha e316cc708b265f401477b7b7eb667725f47aafca

Fix assignment of outputs from class methods. As for inputs, skip over the implicit 'this' parameter.

view details

Martin Whitaker

commit sha 7bed181f680f4598db2a084980d7b889c588dcbf

Support timescales in design units that aren't inside a module. SystemVerilog allows tasks, functions, and classes to be defined at the root level or inside packages, so we can't rely on an enclosing module being present to provide the timescale.

view details

Martin Whitaker

commit sha 27213f2af8c914995db2f6375710ebc258534f3a

Fix for GitHub issue #115 - synthesis aborts on case with max guard of 0. The calculation of the required multiplexer width was incorrect for the corner case of a single guard value of zero.

view details

Martin Whitaker

commit sha b1b91f49c85dfe13e021af5cf56422a87d148b40

Update vlog95 target to handle timescales for root scope tasks/functions.

view details

Martin Whitaker

commit sha 191811f78f03f4d81931335be98f9d36e89ae015

Merge branch 'conda-fix' of https://github.com/tfors/iverilog

view details

Martin Whitaker

commit sha 7d5f6c551a2fef5ec4940bf6a5e2a4844b88df4d

Fix unused variable warning and assumed buffer size from last merge.

view details

Martin Whitaker

commit sha 2bc42fc6e2c9ab5e6e59e86dcabdf22401bc0690

Fix for GitHub issue #104 - assigning hierarchical signal from top level task. When emitting a design, all scopes must be emitted before emitting any top level task/function/method definitions, otherwise hierarchical references can't always be resolved.

view details

Martin Whitaker

commit sha 8461e1d9c415f8152c98c58728656c82f88cd84a

Fix vlog95 target to handle hierarchical references in root-level tasks.

view details

Martin Whitaker

commit sha b51e58fa9db937561697b75086f865001b2b2ac4

Fix for br1007 - out-of-range constant bit select should be a warning. An out-of-range constant bit select on the LHS of an assignment was being treated as an error, whereas an out-of range constant part select would only result in a warning. In any other context, either case would result in a warning, so convert the error to a warning. In addition, all warnings for out-of-range or undefined constant bit/part selects should be controlled by -Wselect-range.

view details

Cary R

commit sha 13189f74312f28c7fdaaed704cc68447bdaaf807

Update fstapi.c to latest from GTKWave

view details

Cary R

commit sha 1d4230472a24358a07a067c2a4ca1963926aa409

Fix getting timeunit outside of module to use a defined check value

view details

Cary R

commit sha 446e825ed315cc20a249e6328f4302fd2dc7c365

Fix space issues

view details

push time in 2 months

create barnchminux/iverilog

branch : fix-make-j-install

created branch time in 2 months

startedvowstar/gitbook-plugin-wavedrom

started time in 2 months

issue commentgolang/go

proposal: cmd/go: add GOMIPS64=r2 for mips64r2 code generation

I think just sampling general Linux distributions will give skewed results, at least for an embedded focused architecture like MIPS.

Debian and Fedora mostly target desktop-capable systems, but most MIPS systems are actually used in embedded systems. (e.g. most in routers and runs more embedded flavored distributions like OpenWRT.)

To put it another way, the reason that Debian/Fedora requires MIPS64r2 might not be that there aren't many pre-MIPS64r2 machines out there, but most pre-MIPS64r2 machines are not powerful enough to support desktop. Gentoo is better indication because Gentoo can be (and more likely to be) used on those smaller machines. (I use Gentoo on Loongson 2F laptop.)

Also, it's also not true that products introduced after MIPS64r2 introduction will support MIPS64r2. Unlike x86, and perhaps ARM, MIPS is widely implemented by individual companies, not licensed from the company that defines the MIPS ISA. Therefore, it might take a long time for a new revision of ISA to propagate to products. Also, for embedded architectures like MIPS, their average product half life will also be significantly longer than more mainstream architectures like x86, so only consider new products ignores all those working products already deployed in the field that could be benefited by Go.

The most likely significant new instruction in MIPS64r2 for Go is probably sign extension. Rotation is not used much in general purpose code, and fma is most likely used in math kernels that probably could benefit from separate assembly implementations and most embedded MIPS64 processors don't have FPU anyway, so supporting fma might not be that crucial.

Lastly, given the current situation with the company that governs the MIPS ISA and the rise of RISC-V, I personally think MIPS usage will gradually decline and remaining uses will be even more focused on embedded than general purpose computing. In the long run, it might not be worthwhile to invest more in MIPS, than in free and open alternatives like RISC-V.

mengzhuo

comment created time in 3 months

issue commentgolang/go

proposal: cmd/go: add GOMIPS64=r2 for mips64r2 code generation

I think the same (making sure the advantage is big enough to warrant the change) can be said for adding a new GOMIPS64 option. A new option will mean more compiler complexity which makes maintaining the compiler and changing the compiler harder. E.g. making any generic rule change needs to understand and test one more configuration. This thereby also has an impact on optimizations efforts for other architectures. This also brings the question if there is capacity to add a new buildbot to make sure neither r2 or non-r2 ports regresses.

I totally agree. My intention (that I didn't make clear in my last reply) is to first see the performance impact and then start discussing potential ways forward. Adding GOMIPS64=r2 is the first option if the performance impact is good enough, and rising minimum requirement should be treated as a last resort (my thinking is that, the minimum requirement should be set such that, without those instructions, basic Go features don't even work without extreme efforts. As a concrete example, for a RISC-V port [where it has clearly defined ISA subsets], D/F [double/single precision floating point] should definitely be optional, and it's reasonable to require I [integer], A [atomic] and M [multiplication] extensions. Anything beyond IMA, should not be required by Go.

In fact, I think that's precisely the criteria for some of the mainstream architectures like 386 and amd64. I guess we won't even consider a proposal to raise minimum required amd64 ISA to AVX, even though AVX processors became available in 2011 and AVX should bring significant performance boost for lots of programs (not to mention that VEX 3-operand format will simplify compiler support). Yet, we are considering raising MIPS minimum requirement for product that was introduced two years earlier (Loongson 3A introduced in 2009 is the first Loongson to support r2.) Given the number of people running Go on modern amd64 hardware and the potential benefits, it is probably worthwhile to introduce AVX support via an hypothetical GOX86=avx option, but the proposed GOMIPS64=r2 meets neither of these two bars (very wide-spread hardware support & significant performance benefits).

We have a policy for using assembly code in packages ( https://golang.org/wiki/AssemblyPolicy), but IMO we don't have a policy for adding ISA variants to compilers. Perhaps it's time to draft such a policy and set some specific requirements.

mengzhuo

comment created time in 3 months

issue commentgolang/go

proposal: cmd/go: add GOMIPS64=r2 for mips64r2 code generation

Loongson 2F is still using MIPS III. 2A is the first Loongson to support MIPS64r2, but it is released only 10 years ago. (FTR, i386 port still supports Pentium MMX, which was released 23 years ago!)

I regret very much that I didn't push back hard enough on bumping minimum architecture for BE ppc64, and that removed a lot of perfectly reasonable hardware to run Go. I hope this won't happen for mips64.

The list of additional instructions to that we could use for MIPS64r2 doesn't look common/generic enough to risk removing support for old hardware. I think we need clear demonstration that using more advanced instruction could lead to non-trivial performance gain for general Go programs before even considering bumping the minimal requirement.

I'm OK with adding GOMIPS64=r2, and adding new instructions to assembler, but not ok with bumping minimal architecture requirement.

mengzhuo

comment created time in 3 months

push eventkendryte/kflash.py

minux

commit sha 5783d8d85e7397007a3ba1394a93d3f9f8ad982f

kflash.py: make -B option help text always up to date Fixes #36.

view details

push time in 5 months

issue closedkendryte/kflash.py

Confusing help text

The "help" text of you tool regarding the boards says

 -B BOARD, --Board BOARD
                        Select dev board, e.g. kd233, dan, bit, goD, goE or
                        trainer

This is out of sync with the actually possible choices which you only know if you read the source code

https://github.com/kendryte/kflash.py/blob/601aad359ecc60e82e2feb8aa545845c176f3be8/kflash.py#L1109

Why don't you just use the choices=.. version for the parser so that it automatically prints all available choices, which are then not out-of-sync with the actual source code? (docs). This way, users are confused about the actual choices for -B.

closed time in 5 months

maxgerhardt

issue commentkendryte/nncase

请问会有预编译的macOS版本吗?

xtensor 装了么?

tsycnh

comment created time in 5 months

more