TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Zinc: a low level language between assembler, C and C++ with Ruby-like syntax

116 点作者 tianyicui超过 14 年前

10 条评论

psnj超过 14 年前
I was surprised by my almost-panicky reaction to seeing:<p><pre><code> Identifiers Can Have Blanks open_window_with_attributes(...) becomes: open window with attributes (...) </code></pre> I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them.<p>I guess I'm old.
评论 #2031652 未加载
评论 #2031796 未加载
评论 #2031792 未加载
评论 #2031685 未加载
评论 #2032426 未加载
thesz超过 14 年前
Another Zinc: <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6772" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6...</a><p>That one is more popular, it eventually became OCaml.
评论 #2033624 未加载
评论 #2032187 未加载
wbhart超过 14 年前
What is wrong with 64 bit integers? Maybe they've been indicted on war crimes or something. The number of languages that appear and don't support them.... And what about interfacing with C? I can count the languages on one hand that have a simple and efficient C interface! (I have a list of other things almost always ignored by languages for no good reason... efficiency, friendly license, lack of macros or ability to extend the language...)
wildmXranat超过 14 年前
Interesting find. It seems to have been left to collect dust. Last changes are about 3 years ago.
paperclip超过 14 年前
I will try to ignore the shallow (but horrifying) issue of identifiers including spaces.<p>The real question to be asked here is what is wrong with the current portable assembler (C) ? C has occupied this niche for a long time and quite successfully - I believe all current mainstream kernels are written in C (or possibly a limited subset of C++).<p>If you want a 'portable assembler', a modern C compiler is in my opinion, a good choice:<p><pre><code> - a solid specification: detailing the behaviour of operations, what is defined, implementation, or undefined behaviour. - access to platform specific features through builtins and intrinsics - ability to use inline asm if you really want to (or need to) - easy integration with existing libraries - minimal dependencies on a runtime library (pretty much none in freestanding implementations) - most compliers give have ways to get good control of both what code is generated and structure layout. </code></pre> The modern C ecosystem provides (mostly good) tools for:<p><pre><code> - tracking memory leaks/invalid memory accesses (valgrind) - static analysis (clang static analyser, sparse, coverity, ...) - debuggers (gdb ...) - solid optimizing compilers (icc, gcc, llvm) - profilers (oprofile, perf, vtune, ...) </code></pre> Admittedly, most of these tools don't depend on the code being written in C, but I suspect any new language would take a while to get properly integrated. If you want to use a low level language, you really want to have access to these tools or equivalent.<p>A new language trying to compete in this space would have to offer something fairly substantial to get me to switch - and a strange syntax like zinc is not going to help. From the documentation at least, zinc seems to currently be missing: an equivalent to volatile; asm; anyway to access a CAS like instruction; 64bit types; floats; a way to interface to C code; clear documentation about behaviour in corner cases (what happens if you a left shift a 32bit value by 40?). The only thing seems to bring to the table to compensate is the ability to inherit structures
评论 #2033300 未加载
评论 #2037038 未加载
humbledrone超过 14 年前
I guarantee that I would confuse the types "byte" (uint8_t) and "octet" (int8_t). The typical distinction between a byte and an octet has to do with the number of bits in the representation (a byte usually has 8, an octet always has 8). I don't know of any convention for bytes being unsigned and octets being signed.
评论 #2034374 未加载
timrobinson超过 14 年前
This reminds me of a slightly higher-level High Level Assembly: <a href="http://en.wikipedia.org/wiki/High_Level_Assembly" rel="nofollow">http://en.wikipedia.org/wiki/High_Level_Assembly</a><p>Edit: the HLA web site always used to be a decent place to learn assembly language. I don't remember it being so mauve though: <a href="http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.html" rel="nofollow">http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.h...</a>
gasull超过 14 年前
Related: assembly programming with Python syntax.<p><a href="http://www.corepy.org/" rel="nofollow">http://www.corepy.org/</a>
gcv超过 14 年前
From the description: "The goal is to have a portable assembler." Why not just use Fortran?
yawniek超过 14 年前
looks interesting but i cant get it to work on os x or linux.
评论 #2033107 未加载